From: Robert Dewar Date: Tue, 31 Oct 2006 17:55:39 +0000 (+0100) Subject: exp_dbug.ads, [...] (Get_External_Name): Add missing initialization of Homonym_Len. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=108e13eb74bd925fba2a6e2e692bd1de1342fd3c;p=gcc.git exp_dbug.ads, [...] (Get_External_Name): Add missing initialization of Homonym_Len. 2006-10-31 Robert Dewar * 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 --- diff --git a/gcc/ada/exp_dbug.adb b/gcc/ada/exp_dbug.adb index 1ad503c6dee..babdef20daf 100644 --- a/gcc/ada/exp_dbug.adb +++ b/gcc/ada/exp_dbug.adb @@ -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 diff --git a/gcc/ada/exp_dbug.ads b/gcc/ada/exp_dbug.ads index ccd80f38f8a..49979e30b8d 100644 --- a/gcc/ada/exp_dbug.ads +++ b/gcc/ada/exp_dbug.ads @@ -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. - - -- 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). + + -- 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. + + -- 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. - - -- 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. + -- 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 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 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 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 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). - - -- 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. + -- 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 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;