This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Stabs: missing parent type reference in description of record field


Hello,

Compiling the following Ada package with -gstabs+
<<
package Rep is
  
   type Agent is (B, O, N, D);
  
   type James is record
      License_To_Kill : Boolean;
      Secret  : Agent;
      Partner : Agent;
   end record;
   for James use record
      License_To_Kill at  0 range 0 .. 31;
      Secret          at  4 range 0 .. 47;
      Partner         at 10 range 0 .. 15;
   end record;

end Rep;
>>

GNAT generates the following stabs for type James:
<<
.stabs
+"rep__james:Tt(0,30)=s12license_to_kill:(0,31)=r(0,31);0000000000000;0000000000
+001;,0,32;secret:(0,32)=@s48;r(0,32);0000000000000;0000000000003;,32,48;partner
+:(0,33)=@s16;r(0,29);0;3;,80,16;;",128,0,5,0
>>

This (mis)leads GDB into generating the following ptype output:
<<
(gdb) ptype james
type = record
    license_to_kill: range 0 .. 1;  <<---   Should be "false .. true"
    secret: range 0 .. 3;           <<---   Should be "b .. d", just
    partner: range b .. d;                  as partner
end record
>>

The problem with "license_to_kill" and "secret" is that it does not reference
the "parent" type (ie type Boolean and type Agent, respectively).

I believe the correct line should be:
<<
.stabs
+"rep__inner:[...]license_to_kill:(0,31)=r(0,6);[...]secret:(0,32)=@s48;r(0,29);
+[...]"
>>
where (0,6) is the boolean type number, and (0,29) is the agent type number.

The attached patch should fix the problem. The ChangeLog is:

2002-04-12  Joel Brobecker  <brobecker@gnat.com>

	* dbxout.c (dbxout_type): When printing the type index of a range
	type which bounds need to be generated in octal format, print
	the type of the parent type if it exists. This makes sure that
	enumerated type descriptions are not inadvertandly transformed
	into plain unsigned types.

Incidentally, I wonder if all the logic of deciding whether the bounds
needs to be written in octal should not be moved inside
dbxout_range_type. This large "if" condition would be moved there and
the current code

        if (...) {
          /* print the type description with bounds in octal */
        else
          dbxout_range_type (type);

would collapse into a simple call to dbxout_range_type ().

Richard Kenner also suggested that we limit the change to the cases
where the parent type is an enumerated type, since this is the only case
that I know of which has visible consequences.

I still prefer the approach I suggest in the patch, because the
information provided is then more precise. With this approach, a stabs
consumer can print the following information about a subtype, even
a type derived from an integer type:

   type <subtype> is <type> range <low-bound> .. <high-bound>

If we restrict the change to enumerated types, the best that can
be done becomes:

   type <subtype> is range <low-bound> .. <high-bound>


-- 
Joel

Attachment: dbxout.c.diff
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]