-- --
-- S p e c --
-- --
--- --
--- Copyright (C) 1996-2002 Free Software Foundation, Inc. --
+-- Copyright (C) 1996-2003 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- --
with Types; use Types;
with Uintp; use Uintp;
-with Get_Targ; use Get_Targ;
package Exp_Dbug is
-- the type, the string "PT", and a suffix which is P or N, depending on
-- whether this is the protected/non-locking version of the operation.
+ -- Operations generated for protected entries follow the same encoding.
+ -- Each entry results in two suprograms: a procedure that holds the
+ -- entry body, and a function that holds the evaluation of the barrier.
+ -- The names of these subprograms include the prefix 'E' or 'B' res-
+ -- pectively. The names also include a numeric suffix to render them
+ -- unique in the presence of overloaded entries.
+
-- Given the declaration:
- -- protected type lock is
- -- function get return integer;
- -- procedure set (x: integer);
+ -- protected type Lock is
+ -- function Get return Integer;
+ -- procedure Set (X: Integer);
+ -- entry Update (Val : Integer);
-- private
- -- value : integer := 0;
- -- end lock;
+ -- Value : Integer := 0;
+ -- end Lock;
-- the following operations are created:
-- lockPT_getN
-- lockPT_getP,
+
-- lockPT_setN
-- lockPT_setP
+ -- lockPT_update1sE
+ -- lockPT_udpate2sB
+
----------------------------------------------------
-- Conversion between Entities and External Names --
----------------------------------------------------
- No_Dollar_In_Label : constant Boolean := Get_No_Dollar_In_Label;
- -- True iff the target allows dollar signs ("$") in external names
+ No_Dollar_In_Label : constant Boolean := True;
+ -- True iff the target does not allow dollar signs ("$") in external names
+ -- ??? We want to migrate all platforms to use the same convention.
+ -- As a first step, we force this constant to always be True. This
+ -- constant will eventually be deleted after we have verified that
+ -- the migration does not cause any unforseen adverse impact.
+ -- We chose "__" because it is supported on all platforms, which is
+ -- not the case of "$".
procedure Get_External_Name
(Entity : Entity_Id;
-- by homonym suffix, if the entity is an overloaded subprogram
-- or is defined within an overloaded subprogram.
-- - the string "___" followed by Suffix
-
- ----------------------------
- -- Debug Name Compression --
- ----------------------------
-
- -- The full qualification of names can lead to long names, and this
- -- section describes the method used to compress these names. Such
- -- compression is attempted if one of the following holds:
-
- -- The length exceeds a maximum set in hostparm, currently set
- -- to 128, but can be changed as needed.
-
- -- The compiler switch -gnatC is set, setting the Compress_Debug_Names
- -- switch in Opt to True.
-
- -- If either of these conditions holds, name compression is attempted
- -- by replacing the qualifying section as follows.
-
- -- Given a name of the form
-
- -- a__b__c__d
-
- -- where a,b,c,d are arbitrary strings not containing a sequence
- -- of exactly two underscores, the name is rewritten as:
-
- -- XC????????_d
-
- -- where ???????? are 8 hex digits representing a 32-bit checksum
- -- value that identifies the sequence of compressed names. In
- -- addition a dummy type declaration is generated as shown by
- -- the following example. Supposed we have three compression
- -- sequences
-
- -- XC1234abcd corresponding to a__b__c__ prefix
- -- XCabcd1234 corresponding to a__b__ prefix
- -- XCab1234cd corresponding to a__ prefix
-
- -- then an enumeration type declaration is generated:
-
- -- type XC is
- -- (XC1234abcdXnn, aXnn, bXnn, cXnn,
- -- XCabcd1234Xnn, aXnn, bXnn,
- -- XCab1234cdXnn, aXnn);
-
- -- showing the meaning of each compressed prefix, so the debugger
- -- can interpret the exact sequence of names that correspond to the
- -- compressed sequence. The Xnn suffixes in the above are simply
- -- serial numbers that are guaranteed to be different to ensure
- -- that all names are unique, and are otherwise ignored.
+ --
+ -- If this procedure is called in the ASIS mode, it does nothing. See the
+ -- comments in the body for more details.
--------------------------------------------
-- Subprograms for Handling Qualification --
-- are useful to remove qualification from a name qualified by the
-- call to Qualify_All_Entity_Names.
- procedure Generate_Auxiliary_Types;
- -- The process of qualifying names may result in name compression which
- -- requires dummy enumeration types to be generated. This subprogram
- -- ensures that these types are appropriately included in the tree.
-
--------------------------------
-- Handling of Numeric Values --
--------------------------------
-- the case where one or both of the bounds are discriminants or
-- variable.
- -- Note: at the current time, we also encode static bounds if they
- -- do not match the natural machine type bounds, but this may be
- -- removed in the future, since it is redundant for most debugging
- -- formats. However, we do not ever need XD encoding for enumeration
- -- base types, since here it is always clear what the bounds are
- -- from the number of enumeration literals, and of course we do
- -- not need to encode the dummy XR types generated for renamings.
+ -- Note: at the current time, we also encode compile time known
+ -- bounds if they do not match the natural machine type bounds,
+ -- but this may be removed in the future, since it is redundant
+ -- for most debugging formats. However, we do not ever need XD
+ -- encoding for enumeration base types, since here it is always
+ -- clear what the bounds are from the total number of enumeration
+ -- literals, and of course we do not need to encode the dummy XR
+ -- types generated for renamings.
-- typ___XD
-- typ___XDL_lowerbound
-- correspond in a natural manner to its size), then it is left
-- unencoded. The above encoding forms are used when there is a
-- constrained range that does not correspond to the size or that
- -- has discriminant references or other non-static bounds.
+ -- has discriminant references or other compile time known bounds.
-- The first form is used if both bounds are dynamic, in which case
-- two constant objects are present whose names are typ___L and
-- name as either a decimal integer, or as the discriminant name.
-- The third form is similarly used if the lower bound is dynamic,
- -- but the upper bound is static or a discriminant reference, in
- -- which case the lower bound is stored in a constant object of
- -- name typ___L, and the upper bound is encoded directly into the
- -- name as either a decimal integer, or as the discriminant name.
+ -- but the upper bound is compile time known or a discriminant
+ -- reference, in which case the lower bound is stored in a constant
+ -- object of name typ___L, and the upper bound is encoded directly
+ -- into the name as either a decimal integer, or as the discriminant
+ -- name.
-- The fourth form is used if both bounds are discriminant references
- -- or static values, with the encoding first for the lower bound,
- -- then for the upper bound, as previously described.
+ -- or compile time known values, with the encoding first for the lower
+ -- bound, then for the upper bound, as previously described.
-------------------
-- Modular Types --
-- Here lowerbound and upperbound are decimal integers, with the
-- usual (postfix "m") encoding for negative numbers. Biased
- -- types are only possible where the bounds are static, and the
- -- values are represented as unsigned offsets from the lower
- -- bound given. For example:
+ -- types are only possible where the bounds are compile time
+ -- known, and the values are represented as unsigned offsets
+ -- from the lower bound given. For example:
-- type Q is range 10 .. 15;
-- for Q'size use 3;
-- type___XVU
-- The former name is used for a record and the latter for the union
- -- that is made for a variant record (see below) if that union has
- -- variable size. These encodings suffix any other encodings that
- -- might be suffixed to the type name.
+ -- that is made for a variant record (see below) if that record or
+ -- union has a field of variable size or if the record or union itself
+ -- has a variable size. These encodings suffix any other encodings that
+ -- that might be suffixed to the type name.
-- The idea here is to provide all the needed information to interpret
-- objects of the original type in the form of a "fixed up" type, which
-- 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.
+ -- 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.
-- type p__z___XR is
-- (p__g___XEXS1XS5XRmXL2XS3);
- -- p__q___XE--------------------outer entity is g
+ -- p__g___XE--------------------outer entity is g
-- XS1-----------------first subscript for g
-- XS5--------------second subscript for g
-- XRm-----------select field m
-- Thin Pointers
- -- Thin pointers are represented as a pointer to the ARRAY field of
- -- a structure with two fields. The name of the structure type is
- -- that of the unconstrained array followed by "___XUT".
-
- -- The field ARRAY contains the array value. This array field is
- -- typically a variable-length array, and consequently the entire
- -- record structure will be encoded as previously described,
- -- resulting in a type with suffix "___XUT___XVE".
-
- -- The field BOUNDS is a struct containing the bounds as above.
+ -- 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 --
-- the second enumeration literal would be named QU43 and the
-- value assigned to it would be 1.
+ ----------------------------
+ -- Effect of Optimization --
+ ----------------------------
+
+ -- 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.
+
end Exp_Dbug;
OSDN Git Service
