mirror/gcc
2
0
Fork 0
mirror of git://gcc.gnu.org/git/gcc.git synced 2025-03-23 00:41:25 +08:00
Code Issues Packages Projects Releases Wiki Activity

exp_dbug.ads, [...] (Get_External_Name): Add missing initialization of Homonym_Len.

Browse Source 
2006-10-31  Robert Dewar  <dewar@adacore.com>

	* exp_dbug.ads, exp_dbug.adb (Get_External_Name): Add missing
	initialization of Homonym_Len.
	(Fully_Qualify_Name): Remove kludge to eliminate anonymous block
	names from fully qualified name. Fixes problem of duplicate
	external names differing only in the presence of such a block name.

From-SVN: r118263
This commit is contained in:
Robert Dewar 2006-10-31 18:55:39 +01:00 committed by Arnaud Charlet
parent ae5dd59d04
commit 108e13eb74
2 changed files with 255 additions and 281 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

38
gcc/ada/exp_dbug.adb
View File

@ -36,7 +36,6 @@ with Output; use Output;
with Sem_Eval; use Sem_Eval;
with Sem_Util; use Sem_Util;
with Sinfo; use Sinfo;
with Snames; use Snames;
with Stand; use Stand;
with Stringt; use Stringt;
with Table;
@ -546,7 +545,6 @@ package body Exp_Dbug is
-- Vax floating-point case
elsif Vax_Float (E) then
if Digits_Value (Base_Type (E)) = 6 then
Get_External_Name_With_Suffix (E, "XFF");
@ -679,13 +677,13 @@ package body Exp_Dbug is
else
Get_Name_String_And_Append (Chars (Entity));
end if;
end Get_Qualified_Name_And_Append;
-- Start of processing for Get_External_Name
begin
Name_Len := 0;
Name_Len := 0;
Homonym_Len := 0;
-- If this is a child unit, we want the child
@ -887,9 +885,10 @@ package body Exp_Dbug is
------------------------------------
procedure Get_Secondary_DT_External_Name
(Typ : Entity_Id;
Ancestor_Typ : Entity_Id;
Suffix_Index : Int) is
(Typ : Entity_Id;
Ancestor_Typ : Entity_Id;
Suffix_Index : Int)
is
begin
Get_External_Name (Typ, Has_Suffix => False);
@ -1116,26 +1115,13 @@ package body Exp_Dbug is
Get_Name_String (Chars (E));
end if;
-- A special check here, we never add internal block or loop
-- names, since they intefere with debugging. We identify these
-- by the fact that they start with an upper case B or L.
-- But do add these if what we are qualifying is a __clean
-- procedure since those need to be made unique.
-- Here we do one step of the qualification
if (Name_Buffer (1) = 'B' or else Name_Buffer (1) = 'L')
and then (not Debug_Flag_VV)
and then Full_Qualify_Len > 2
and then Chars (Ent) /= Name_uClean
then
Full_Qualify_Len := Full_Qualify_Len - 2;
else
Full_Qualify_Name
(Full_Qualify_Len + 1 .. Full_Qualify_Len + Name_Len) :=
Name_Buffer (1 .. Name_Len);
Full_Qualify_Len := Full_Qualify_Len + Name_Len;
Append_Homonym_Number (E);
end if;
Full_Qualify_Name
(Full_Qualify_Len + 1 .. Full_Qualify_Len + Name_Len) :=
Name_Buffer (1 .. Name_Len);
Full_Qualify_Len := Full_Qualify_Len + Name_Len;
Append_Homonym_Number (E);
end if;
if Is_BNPE (E) then

498
gcc/ada/exp_dbug.ads
View File

@ -6,7 +6,7 @@
-- --
-- S p e c --
-- --
-- Copyright (C) 1996-2005, Free Software Foundation, Inc. --
-- Copyright (C) 1996-2006, Free Software Foundation, Inc. --
-- --
-- GNAT is free software; you can redistribute it and/or modify it under --
-- terms of the GNU General Public License as published by the Free Soft- --
@ -50,18 +50,18 @@ package Exp_Dbug is
-- as described in Namet). Upper case letters are used only for entities
-- generated by the compiler.
-- There are two cases, global entities, and local entities. In more
-- formal terms, local entities are those which have a dynamic enclosing
-- scope, and global entities are at the library level, except that we
-- always consider procedures to be global entities, even if they are
-- nested (that's because at the debugger level a procedure name refers
-- to the code, and the code is indeed a global entity, including the
-- case of nested procedures.) In addition, we also consider all types
-- to be global entities, even if they are defined within a procedure.
-- There are two cases, global entities, and local entities. In more formal
-- terms, local entities are those which have a dynamic enclosing scope,
-- and global entities are at the library level, except that we always
-- consider procedures to be global entities, even if they are nested
-- (that's because at the debugger level a procedure name refers to the
-- code, and the code is indeed a global entity, including the case of
-- nested procedures.) In addition, we also consider all types to be global
-- entities, even if they are defined within a procedure.
-- The reason for treating all type names as global entities is that
-- a number of our type encodings work by having related type names,
-- and we need the full qualification to keep this unique.
-- The reason for treating all type names as global entities is that a
-- number of our type encodings work by having related type names, and we
-- need the full qualification to keep this unique.
-- For global entities, the encoded name includes all components of the
-- fully expanded name (but omitting Standard at the start). For example,
@ -69,16 +69,16 @@ package Exp_Dbug is
-- there is an entity in this embdded package whose name is S, the encoded
-- name will include the components p.q.r.s.
-- For local entities, the encoded name only includes the components
-- up to the enclosing dynamic scope (other than a block). At run time,
-- such a dynamic scope is a subprogram, and the debugging formats know
-- about local variables of procedures, so it is not necessary to have
-- full qualification for such entities. In particular this means that
-- direct local variables of a procedure are not qualified.
-- For local entities, the encoded name only includes the components up to
-- the enclosing dynamic scope (other than a block). At run time, such a
-- dynamic scope is a subprogram, and the debugging formats know about
-- local variables of procedures, so it is not necessary to have full
-- qualification for such entities. In particular this means that direct
-- local variables of a procedure are not qualified.
-- As an example of the local name convention, consider a procedure V.W
-- with a local variable X, and a nested block Y containing an entity
-- Z. The fully qualified names of the entities X and Z are:
-- with a local variable X, and a nested block Y containing an entity Z.
-- The fully qualified names of the entities X and Z are:
-- V.W.X
-- V.W.Y.Z
@ -95,11 +95,11 @@ package Exp_Dbug is
-- Handling of Overloading --
-----------------------------
-- The above scheme is incomplete with respect to overloaded
-- subprograms, since overloading can legitimately result in a
-- case of two entities with exactly the same fully qualified names.
-- To distinguish between entries in a set of overloaded subprograms,
-- the encoded names are serialized by adding the suffix:
-- The above scheme is incomplete for overloaded subprograms, since
-- overloading can legitimately result in case of two entities with
-- exactly the same fully qualified names. To distinguish between
-- entries in a set of overloaded subprograms, the encoded names are
-- serialized by adding the suffix:
-- __nn (two underscores)
@ -107,9 +107,9 @@ package Exp_Dbug is
-- 3 for the third, etc.). A suffix of __1 is always omitted (i.e. no
-- suffix implies the first instance).
-- These names are prefixed by the normal full qualification. So
-- for example, the third instance of the subprogram qrs in package
-- yz would have the name:
-- These names are prefixed by the normal full qualification. So for
-- example, the third instance of the subprogram qrs in package yz
-- would have the name:
-- yz__qrs__3
@ -126,11 +126,11 @@ package Exp_Dbug is
-- __nn_nn_nn ...
-- where the nn values are the homonym numbers as needed for any of
-- the qualifying entities, separated by a single underscore. If all
-- the nn values are 1, the suffix is omitted, Otherwise the suffix
-- is present (including any values of 1). The following example
-- shows how this suffixing works.
-- where the nn values are the homonym numbers as needed for any of the
-- qualifying entities, separated by a single underscore. If all the nn
-- values are 1, the suffix is omitted, Otherwise the suffix is present
-- (including any values of 1). The following example shows how this
-- suffixing works.
-- package body Yz is
-- procedure Qrs is -- Name is yz__qrs
@ -152,10 +152,10 @@ package Exp_Dbug is
-- Operator Names --
--------------------
-- The above rules applied to operator names would result in names
-- with quotation marks, which are not typically allowed by assemblers
-- and linkers, and even if allowed would be odd and hard to deal with.
-- To avoid this problem, operator names are encoded as follows:
-- The above rules applied to operator names would result in names with
-- quotation marks, which are not typically allowed by assemblers and
-- linkers, and even if allowed would be odd and hard to deal with. To
-- avoid this problem, operator names are encoded as follows:
-- Oabs abs
-- Oand and
@ -179,8 +179,8 @@ package Exp_Dbug is
-- These names are prefixed by the normal full qualification, and
-- suffixed by the overloading identification. So for example, the
-- second operator "=" defined in package Extra.Messages would
-- have the name:
-- second operator "=" defined in package Extra.Messages would have
-- the name:
-- extra__messages__Oeq__2
@ -189,9 +189,9 @@ package Exp_Dbug is
----------------------------------
-- It might be thought that the above scheme is complete, but in Ada 95,
-- full qualification is insufficient to uniquely identify an entity
-- in the program, even if it is not an overloaded subprogram. There
-- are two possible confusions:
-- full qualification is insufficient to uniquely identify an entity in
-- the program, even if it is not an overloaded subprogram. There are
-- two possible confusions:
-- a.b
@ -203,8 +203,8 @@ package Exp_Dbug is
-- interpretation 1: entity c in child package a.b
-- interpretation 2: entity c in nested package b in body of a
-- It is perfectly legal in both cases for both interpretations to
-- be valid within a single program. This is a bit of a surprise since
-- It is perfectly legal in both cases for both interpretations to be
-- valid within a single program. This is a bit of a surprise since
-- certainly in Ada 83, full qualification was sufficient, but not in
-- Ada 95. The result is that the above scheme can result in duplicate
-- names. This would not be so bad if the effect were just restricted
@ -213,7 +213,7 @@ package Exp_Dbug is
-- a real problem of name clashes.
-- To deal with this situation, we provide two additional encoding
-- rules for names
-- rules for names:
-- First: all library subprogram names are preceded by the string
-- _ada_ (which causes no duplications, since normal Ada names can
@ -835,30 +835,30 @@ package Exp_Dbug is
-- Base Record Types --
-----------------------
-- Under certain circumstances, debuggers need two descriptions
-- of a record type, one that gives the actual details of the
-- base type's structure (as described elsewhere in these
-- comments) and one that may be used to obtain information
-- about the particular subtype and the size of the objects
-- being typed. In such cases the compiler will substitute a
-- type whose name is typically compiler-generated and
-- Under certain circumstances, debuggers need two descriptions of a
-- record type, one that gives the actual details of the base type's
-- structure (as described elsewhere in these comments) and one that may
-- be used to obtain information about the particular subtype and the
-- size of the objects being typed. In such cases the compiler will
-- substitute type whose name is typically compiler-generated and
-- irrelevant except as a key for obtaining the actual type.
-- Specifically, if this name is x, then we produce a record
-- type named x___XVS consisting of one field. The name of
-- this field is that of the actual type being encoded, which
-- we'll call y (the type of this single field is arbitrary).
-- Both x and y may have corresponding ___XVE types.
-- The size of the objects typed as x should be obtained from
-- the structure of x (and x___XVE, if applicable) as for
-- ordinary types unless there is a variable named x___XVZ, which,
-- if present, will hold the the size (in bits) of x.
-- Specifically, if this name is x, then we produce a record type named
-- x___XVS consisting of one field. The name of this field is that of
-- the actual type being encoded, which we'll call y (the type of this
-- single field is arbitrary). Both x and y may have corresponding
-- ___XVE types.
-- The type x will either be a subtype of y (see also Subtypes
-- of Variant Records, below) or will contain no fields at
-- all. The layout, types, and positions of these fields will
-- be accurate, if present. (Currently, however, the GDB
-- debugger makes no use of x except to determine its size).
-- The size of the objects typed as x should be obtained from the
-- structure of x (and x___XVE, if applicable) as for ordinary types
-- unless there is a variable named x___XVZ, which, if present, will
-- hold the the size (in bits) of x.
-- The type x will either be a subtype of y (see also Subtypes of
-- Variant Records, below) or will contain no fields at all. The layout,
-- types, and positions of these fields will be accurate, if present.
-- (Currently, however, the GDB debugger makes no use of x except to
-- determine its size).
-- Among other uses, XVS types are sometimes used to encode
-- unconstrained types. For example, given
@ -889,12 +889,11 @@ package Exp_Dbug is
--
-- at1___C_PAD___XVZ: constant Integer := 32 + M * 8 + padding term;
--
-- Not all unconstrained types are so encoded; the XVS
-- convention may be unnecessary for unconstrained types of
-- fixed size. However, this encoding is always necessary when
-- a subcomponent type (array element's type or record field's
-- type) is an unconstrained record type some of whose
-- components depend on discriminant values.
-- Not all unconstrained types are so encoded; the XVS convention may be
-- unnecessary for unconstrained types of fixed size. However, this
-- encoding is always necessary when a subcomponent type (array
-- element's type or record field's type) is an unconstrained record
-- type some of whose components depend on discriminant values.
-----------------
-- Array Types --
@ -906,39 +905,38 @@ package Exp_Dbug is
-- are the names of the types for the bounds. The types of these
-- fields is an integer type which is meaningless.
-- To conserve space, we do not produce this type unless one of
-- the index types is either an enumeration type, has a variable
-- upper bound, has a lower bound different from the constant 1,
-- is a biased type, or is wider than "sizetype".
-- To conserve space, we do not produce this type unless one of the
-- index types is either an enumeration type, has a variable upper
-- bound, has a lower bound different from the constant 1, is a biased
-- type, or is wider than "sizetype".
-- Given the full encoding of these types (see above description for
-- the encoding of discrete types), this means that all necessary
-- information for addressing arrays is available. In some
-- debugging formats, some or all of the bounds information may
-- be available redundantly, particularly in the fixed-point case,
-- but this information can in any case be ignored by the debugger.
-- information for addressing arrays is available. In some debugging
-- formats, some or all of the bounds information may be available
-- redundantly, particularly in the fixed-point case, but this
-- information can in any case be ignored by the debugger.
----------------------------
-- Note on Implicit Types --
----------------------------
-- The compiler creates implicit type names in many situations where
-- a type is present semantically, but no specific name is present.
-- For example:
-- The compiler creates implicit type names in many situations where a
-- type is present semantically, but no specific name is present. For
-- example:
-- S : Integer range M .. N;
-- Here the subtype of S is not integer, but rather an anonymous
-- subtype of Integer. Where possible, the compiler generates names
-- for such anonymous types that are related to the type from which
-- the subtype is obtained as follows:
-- Here the subtype of S is not integer, but rather an anonymous subtype
-- of Integer. Where possible, the compiler generates names for such
-- anonymous types that are related to the type from which the subtype
-- is obtained as follows:
-- T name suffix
-- where name is the name from which the subtype is obtained, using
-- lower case letters and underscores, and suffix starts with an upper
-- case letter. For example, the name for the above declaration of S
-- might be:
-- case letter. For example the name for the above declaration might be:
-- TintegerS4b
@ -985,11 +983,11 @@ package Exp_Dbug is
-- x___XRE for an exception renaming
-- x___XRP for a package renaming
-- The name is fully qualified in the usual manner, i.e. qualified in
-- the same manner as the entity x would be. In the case of a package
-- renaming where x is a child unit, the qualification includes the
-- name of the parent unit, to disambiguate child units with the same
-- simple name and (of necessity) different parents.
-- The name is fully qualified in the usual manner, i.e. qualified in the
-- same manner as the entity x would be. In the case of a package renaming
-- where x is a child unit, the qualification includes the name of the
-- parent unit, to disambiguate child units with the same simple name and
-- (of necessity) different parents.
-- Note: subprogram renamings are not encoded at the present time
@ -1001,17 +999,17 @@ package Exp_Dbug is
-- (y___XE)
-- i.e. the enumeration type has a single field, whose name
-- matches the name y, with the XE suffix. The entity for this
-- enumeration literal is fully qualified in the usual manner.
-- All subprogram, exception, and package renamings fall into
-- this category, as well as simple object renamings.
-- i.e. the enumeration type has a single field, whose name matches
-- the name y, with the XE suffix. The entity for this enumeration
-- literal is fully qualified in the usual manner. All subprogram,
-- exception, and package renamings fall into this category, as
-- well as simple object renamings.
-- For the object renaming case where y is a selected component or an
-- indexed component, the literal name is suffixed by additional fields
-- that give details of the components. The name starts as above with
-- a y___XE entity indicating the outer level variable. Then a series
-- of selections and indexing operations can be specified as follows:
-- that give details of the components. The name starts as above with a
-- y___XE entity indicating the outer level variable. Then a series of
-- selections and indexing operations can be specified as follows:
-- Indexed component
@ -1033,14 +1031,14 @@ package Exp_Dbug is
-- Slice
-- For the slice case, we have two entries. The first is for
-- the lower bound of the slice, and has the form
-- For the slice case, we have two entries. The first is for the
-- lower bound of the slice, and has the form
-- XLnnn
-- XLe
-- Specifies the lower bound, using exactly the same encoding
-- as for an XS subscript as described above.
-- Specifies the lower bound, using exactly the same encoding as
-- for an XS subscript as described above.
-- Then the upper bound appears in the usual XSnnn/XSe form
@ -1158,61 +1156,57 @@ package Exp_Dbug is
-- BV(0) BV(1) BV(2) BV(3) BV(4) BV(5) unused bits
-- Note that if a modular type is used to represent the array, the
-- allocation in memory is not the same as a normal modular type.
-- The difference occurs when the allocated object is larger than
-- the size of the array. For a normal modular type, we extend the
-- value on the left with zeroes.
-- allocation in memory is not the same as a normal modular type. The
-- difference occurs when the allocated object is larger than the size of
-- the array. For a normal modular type, we extend the value on the left
-- with zeroes.
-- For example, in the normal modular case, if we have a 6-bit
-- modular type, declared as mod 2**6, and we allocate an 8-bit
-- object for this type, then we extend the value with two bits
-- on the most significant end, and in either the little-endian
-- or big-endian case, the value 63 is represented as 00111111
-- in binary in memory.
-- For example, in the normal modular case, if we have a 6-bit modular
-- type, declared as mod 2**6, and we allocate an 8-bit object for this
-- type, then we extend the value with two bits on the most significant
-- end, and in either the little-endian or big-endian case, the value 63 is
-- represented as 00111111 in binary in memory.
-- For a modular type used to represent a packed array, the rule is
-- different. In this case, if we have to extend the value, then we
-- do it with undefined bits (which are not initialized and whose value
-- is irrelevant to any generated code). Furthermore these bits are on
-- the right (least significant bits) in the big-endian case, and on the
-- left (most significant bits) in the little-endian case.
-- different. In this case, if we have to extend the value, then we do it
-- with undefined bits (which are not initialized and whose value is
-- irrelevant to any generated code). Furthermore these bits are on the
-- right (least significant bits) in the big-endian case, and on the left
-- (most significant bits) in the little-endian case.
-- For example, if we have a packed boolean array of 6 bits, all set
-- to True, stored in an 8-bit object, then the value in memory in
-- binary is ??111111 in the little-endian case, and 111111?? in the
-- big-endian case.
-- For example, if we have a packed boolean array of 6 bits, all set to
-- True, stored in an 8-bit object, then the value in memory in binary is
-- ??111111 in the little-endian case, and 111111?? in the big-endian case.
-- This is done so that the representation of packed arrays does not
-- depend on whether we use a modular representation or array of bytes
-- as previously described. This ensures that we can pass such values
-- by reference in the case where a subprogram has to be able to handle
-- values stored in either form.
-- as previously described. This ensures that we can pass such values by
-- reference in the case where a subprogram has to be able to handle values
-- stored in either form.
-- Note that when we extract the value of such a modular packed array,
-- we expect to retrieve only the relevant bits, so in this same example,
-- when we extract the value, we get 111111 in both cases, and the code
-- generated by the front end assumes this, although it does not assume
-- that any high order bits are defined.
-- Note that when we extract the value of such a modular packed array, we
-- expect to retrieve only the relevant bits, so in this same example, when
-- we extract the value we get 111111 in both cases, and the code generated
-- by the front end assumes this although it does not assume that any high
-- order bits are defined.
-- There are opportunities for optimization based on the knowledge that
-- the unused bits are irrelevant for these type of packed arrays. For
-- example if we have two such 6-bit-in-8-bit values and we do an
-- assignment:
-- There are opportunities for optimization based on the knowledge that the
-- unused bits are irrelevant for these type of packed arrays. For example
-- if we have two such 6-bit-in-8-bit values and we do an assignment:
-- a := b;
-- Then logically, we extract the 6 bits and store only 6 bits in the
-- result, but the back end is free to simply assign the entire 8-bits
-- in this case, since we don't actually care about the undefined bits.
-- result, but the back end is free to simply assign the entire 8-bits in
-- this case, since we don't actually care about the undefined bits.
-- However, in the equality case, it is important to ensure that the
-- undefined bits do not participate in an equality test.
-- If a modular packed array value is assigned to a register, then
-- logically it could always be held right justified, to avoid any
-- need to shift, e.g. when doing comparisons. But probably this is
-- a bad choice, as it would mean that an assignment such as a := b
-- above would require shifts when one value is in a register and the
-- other value is in memory.
-- logically it could always be held right justified, to avoid any need to
-- shift, e.g. when doing comparisons. But probably this is a bad choice,
-- as it would mean that an assignment such as a := above would require
-- shifts when one value is in a register and the other value is in memory.
------------------------------------------------------
-- Subprograms for Handling Packed Array Type Names --
@ -1222,27 +1216,26 @@ package Exp_Dbug is
(Typ : Entity_Id;
Csize : Uint)
return Name_Id;
-- This function is used in Exp_Pakd to create the name that is encoded
-- as described above. The entity Typ provides the name ttt, and the
-- value Csize is the component size that provides the nnn value.
-- This function is used in Exp_Pakd to create the name that is encoded as
-- described above. The entity Typ provides the name ttt, and the value
-- Csize is the component size that provides the nnn value.
--------------------------------------
-- Pointers to Unconstrained Arrays --
--------------------------------------
-- There are two kinds of pointers to arrays. The debugger can tell
-- which format is in use by the form of the type of the pointer.
-- There are two kinds of pointers to arrays. The debugger can tell which
-- format is in use by the form of the type of the pointer.
-- Fat Pointers
-- Fat pointers are represented as a struct with two fields. This
-- struct has two distinguished field names:
-- P_ARRAY is a pointer to the array type. The name of this
-- type is the unconstrained type followed by "___XUA". This
-- array will have bounds which are the discriminants, and
-- hence are unparsable, but will give the number of
-- subscripts and the component type.
-- P_ARRAY is a pointer to the array type. The name of this type is
-- the unconstrained type followed by "___XUA". This array will have
-- bounds which are the discriminants, and hence are unparsable, but
-- will give the number of subscripts and the component type.
-- P_BOUNDS is a pointer to a struct, the name of whose type is the
-- unconstrained array name followed by "___XUB" and which has
@ -1251,74 +1244,71 @@ package Exp_Dbug is
-- LBn (n a decimal integer) lower bound of n'th dimension
-- UBn (n a decimal integer) upper bound of n'th dimension
-- The bounds may be any integral type. In the case of an
-- enumeration type, Enum_Rep values are used.
-- The bounds may be any integral type. In the case of an enumeration
-- type, Enum_Rep values are used.
-- The debugging information will sometimes reference an anonymous
-- fat pointer type. Such types are given the name xxx___XUP, where
-- xxx is the name of the designated type. If the debugger is asked
-- to output such a type name, the appropriate form is "access xxx".
-- The debugging information will sometimes reference an anonymous fat
-- pointer type. Such types are given the name xxx___XUP, where xxx is
-- the name of the designated type. If the debugger is asked to output
-- such a type name, the appropriate form is "access xxx".
-- Thin Pointers
-- The value of a thin pointer is a pointer to the second field
-- of a structure with two fields. The name of this structure's
-- type is "arr___XUT", where "arr" is the name of the
-- unconstrained array type. Even though it actually points into
-- middle of this structure, the thin pointer's type in debugging
-- information is pointer-to-arr___XUT.
-- The value of a thin pointer is a pointer to the second field of a
-- structure with two fields. The name of this structure's type is
-- "arr___XUT", where "arr" is the name of the unconstrained array
-- type. Even though it actually points into middle of this structure,
-- the thin pointer's type in debugging information is
-- pointer-to-arr___XUT.
-- The first field of arr___XUT is named BOUNDS, and has a type
-- named arr___XUB, with the structure described for such types
-- in fat pointers, as described above.
-- The first field of arr___XUT is named BOUNDS, and has a type named
-- arr___XUB, with the structure described for such types in fat
-- pointers, as described above.
-- The second field of arr___XUT is named ARRAY, and contains
-- the actual array. Because this array has a dynamic size,
-- determined by the BOUNDS field that precedes it, all of the
-- information about arr___XUT is encoded in a parallel type named
-- arr___XUT___XVE, with fields BOUNDS and ARRAY___XVL. As for
-- previously described ___XVE types, ARRAY___XVL has
-- a pointer-to-array type. However, the array type in this case
-- is named arr___XUA and only its element type is meaningful,
-- just as described for fat pointers.
-- The second field of arr___XUT is named ARRAY, and contains the
-- actual array. Because this array has a dynamic size, determined by
-- the BOUNDS field that precedes it, all of the information about
-- arr___XUT is encoded in a parallel type named arr___XUT___XVE, with
-- fields BOUNDS and ARRAY___XVL. As for previously described ___XVE
-- types, ARRAY___XVL has a pointer-to-array type. However, the array
-- type in this case is named arr___XUA and only its element type is
-- meaningful, just as described for fat pointers.
--------------------------------------
-- Tagged Types and Type Extensions --
--------------------------------------
-- A type C derived from a tagged type P has a field named "_parent"
-- of type P that contains its inherited fields. The type of this
-- field is usually P (encoded as usual if it has a dynamic size),
-- but may be a more distant ancestor, if P is a null extension of
-- that type.
-- A type C derived from a tagged type P has a field named "_parent" of
-- type P that contains its inherited fields. The type of this field is
-- usually P (encoded as usual if it has a dynamic size), but may be a more
-- distant ancestor, if P is a null extension of that type.
-- The type tag of a tagged type is a field named _tag, of type void*.
-- If the type is derived from another tagged type, its _tag field is
-- found in its _parent field.
-- The type tag of a tagged type is a field named _tag, of type void*. If
-- the type is derived from another tagged type, its _tag field is found in
-- its _parent field.
-----------------------------
-- Variant Record Encoding --
-----------------------------
-- The variant part of a variant record is encoded as a single field
-- in the enclosing record, whose name is:
-- The variant part of a variant record is encoded as a single field in the
-- enclosing record, whose name is:
-- discrim___XVN
-- where discrim is the unqualified name of the variant. This field name
-- is built by gigi (not by code in this unit). In the case of an
-- Unchecked_Union record, this discriminant will not appear in the
-- record, and the debugger must proceed accordingly (basically it
-- can treat this case as it would a C union).
-- where discrim is the unqualified name of the variant. This field name is
-- built by gigi (not by code in this unit). For Unchecked_Union record,
-- this discriminant will not appear in the record, and the debugger must
-- proceed accordingly (basically it can treat this case as it would a C
-- union).
-- The type corresponding to this field has a name that is obtained
-- by concatenating the type name with the above string and is similar
-- to a C union, in which each member of the union corresponds to one
-- variant. However, unlike a C union, the size of the type may be
-- variable even if each of the components are fixed size, since it
-- includes a computation of which variant is present. In that case,
-- it will be encoded as above and a type with the suffix "___XVN___XVU"
-- will be present.
-- The type corresponding to this field has a name that is obtained by
-- concatenating the type name with the above string and is similar to a C
-- union, in which each member of the union corresponds to one variant.
-- However, unlike a C union, the size of the type may be variable even if
-- each of the components are fixed size, since it includes a computation
-- of which variant is present. In that case, it will be encoded as above
-- and a type with the suffix "___XVN___XVU" will be present.
-- The name of the union member is encoded to indicate the choices, and
-- is a string given by the following grammar:
@ -1335,15 +1325,15 @@ package Exp_Dbug is
-- R1T4S7S10m
-- In the case of enumeration values, the values used are the
-- actual representation values in the case where an enumeration type
-- has an enumeration representation spec (i.e. they are values that
-- correspond to the use of the Enum_Rep attribute).
-- In the case of enumeration values, the values used are the actual
-- representation values in the case where an enumeration type has an
-- enumeration representation spec (i.e. they are values that correspond
-- to the use of the Enum_Rep attribute).
-- The type of the inner record is given by the name of the union
-- type (as above) concatenated with the above string. Since that
-- type may itself be variable-sized, it may also be encoded as above
-- with a new type with a further suffix of "___XVU".
-- The type of the inner record is given by the name of the union type (as
-- above) concatenated with the above string. Since that type may itself be
-- variable-sized, it may also be encoded as above with a new type with a
-- further suffix of "___XVU".
-- As an example, consider:
@ -1362,23 +1352,22 @@ package Exp_Dbug is
-- V1 : Var;
-- In this case, the type var is represented as a struct with three
-- fields, the first two are "disc" and "m", representing the values
-- of these record components.
-- In this case, the type var is represented as a struct with three fields,
-- the first two are "disc" and "m", representing the values of these
-- record components.
-- The third field is a union of two types, with field names S1 and O.
-- S1 is a struct with fields "r" and "s", and O is a struct with
-- fields "t".
-- The third field is a union of two types, with field names S1 and O. S1
-- is a struct with fields "r" and "s", and O is a struct with fields "t".
------------------------------------------------
-- Subprograms for Handling Variant Encodings --
------------------------------------------------
procedure Get_Variant_Encoding (V : Node_Id);
-- This procedure is called by Gigi with V being the variant node.
-- The corresponding encoding string is returned in Name_Buffer with
-- the length of the string in Name_Len, and an ASCII.NUL character
-- stored following the name.
-- This procedure is called by Gigi with V being the variant node. The
-- corresponding encoding string is returned in Name_Buffer with the length
-- of the string in Name_Len, and an ASCII.NUL character stored following
-- the name.
---------------------------------
-- Subtypes of Variant Records --
@ -1405,38 +1394,37 @@ package Exp_Dbug is
-- V2 : Var (True);
-- V3 : Var (False);
-- Here V2 for example is represented with a subtype whose name is
-- something like TvarS3b, which is a struct with three fields. The
-- first two fields are "disc" and "m" as for the base type, and
-- the third field is S1, which contains the fields "r" and "s".
-- Here V2, for example, is represented with a subtype whose name is
-- something like TvarS3b, which is a struct with three fields. The first
-- two fields are "disc" and "m" as for the base type, and the third field
-- is S1, which contains the fields "r" and "s".
-- The debugger should simply ignore structs with names of the form
-- corresponding to variants, and consider the fields inside as
-- belonging to the containing record.
-- corresponding to variants, and consider the fields inside as belonging
-- to the containing record.
-------------------------------------------
-- Character literals in Character Types --
-------------------------------------------
-- Character types are enumeration types at least one of whose
-- enumeration literals is a character literal. Enumeration literals
-- are usually simply represented using their identifier names. In
-- the case where an enumeration literal is a character literal, the
-- name aencoded as described in the following paragraph.
-- Character types are enumeration types at least one of whose enumeration
-- literals is a character literal. Enumeration literals are usually simply
-- represented using their identifier names. If the enumeration literal is
-- a character literal, the name aencoded as described in the following
-- paragraph.
-- A name QUhh, where each 'h' is a lower-case hexadecimal digit,
-- stands for a character whose Unicode encoding is hh, and
-- QWhhhh likewise stands for a wide character whose encoding
-- is hhhh. The representation values are encoded as for ordinary
-- enumeration literals (and have no necessary relationship to the
-- values encoded in the names).
-- A name QUhh, where each 'h' is a lower-case hexadecimal digit, stands
-- for a character whose Unicode encoding is hh, and QWhhhh likewise stands
-- for a wide character whose encoding is hhhh. The representation values
-- are encoded as for ordinary enumeration literals (and have no necessary
-- relationship to the values encoded in the names).
-- For example, given the type declaration
-- type x is (A, 'C', B);
-- the second enumeration literal would be named QU43 and the
-- value assigned to it would be 1.
-- the second enumeration literal would be named QU43 and the value
-- assigned to it would be 1.
-----------------------------------------------
-- Secondary Dispatch tables of tagged types --
@ -1448,9 +1436,9 @@ package Exp_Dbug is
Suffix_Index : Int);
-- Set Name_Buffer and Name_Len to the external name of one secondary
-- dispatch table of Typ. If the interface has been inherited from some
-- ancestor then Ancestor_Typ is such node (in this case the secondary
-- DT is needed to handle overriden primitives); if there is no such
-- ancestor then Ancestor_Typ is equal to Typ.
-- ancestor then Ancestor_Typ is such node (in this case the secondary DT
-- is needed to handle overriden primitives); if there is no such ancestor
-- then Ancestor_Typ is equal to Typ.
--
-- Internal rule followed for the generation of the external name:
--
@ -1464,11 +1452,11 @@ package Exp_Dbug is
-- External_Name (Typ) + '_' + External_Name (Ancestor_Typ)
-- + Suffix_Number + 'P'
--
-- Note: We have to use the external names (instead of simply their
-- names) to protect the frontend against programs that give the same
-- name to all the interfaces and use the expanded name to reference
-- them. The Suffix_Number is used to differentiate all the secondary
-- dispatch tables of a given type.
-- Note: We have to use the external names (instead of simply their names)
-- to protect the frontend against programs that give the same name to all
-- the interfaces and use the expanded name to reference them. The
-- Suffix_Number is used to differentiate all the secondary dispatch
-- tables of a given type.
--
-- Examples:
--
@ -1503,14 +1491,14 @@ package Exp_Dbug is
----------------------------
-- If the program is compiled with optimization on (e.g. -O1 switch
-- specified), then there may be variations in the output from the
-- above specification. In particular, objects may disappear from
-- the output. This includes not only constants and variables that
-- the program declares at the source level, but also the x___L and
-- x___U constants created to describe the lower and upper bounds of
-- subtypes with dynamic bounds. This means for example, that array
-- bounds may disappear if optimization is turned on. The debugger
-- is expected to recognize that these constants are missing and
-- deal as best as it can with the limited information available.
-- specified), then there may be variations in the output from the above
-- specification. In particular, objects may disappear from the output.
-- This includes not only constants and variables that the program declares
-- at the source level, but also the x___L and x___U constants created to
-- describe the lower and upper bounds of subtypes with dynamic bounds.
-- This means for example, that array bounds may disappear if optimization
-- is turned on. The debugger is expected to recognize that these constants
-- are missing and deal as best as it can with the limited information
-- available.
end Exp_Dbug;