This is the mail archive of the 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]

Re: [PING*4] add support for dwarf AT_GNU_descriptive_type

Olivier Hainque wrote:
Hi Jason,

Any further opinion or question on this topic ?

Hi Oliver --

I took another look over the thread.  I'm not very familiar
with Ada, but I don't understand why your example requires
a new DWARF type.  I'm not familiar with this idea of a
"parallel type" or what the "complex aspects" are that you

You show a snippet of code which shows printing 'b' at a
breakpoint.  Are 'B' and 'b' the same object?

I would like to see how 'b' is currently described in DWARF
and how you would propose changing it, so that I have a better
understanding of why a debugger cannot print 'b' in detail.

You might also want to discuss this on

Thanks in advance,


Olivier Hainque wrote:
Jason Merrill wrote:
Sorry for the delay in review.
No problem. Thanks for taking the time to get to it.

This patch looks reasonable, but I'm not sure why it's necessary. How does the generated debug info change with this patch?
 For a type with complex aspects (more below) we now also get debug info for
 a "parallel" type with the complex aspects encoded within simple attributes
 (e.g. in record field names), and an extra attribute is attached to the
 original type DIE to designate the parallel type.

 The extra attribute code is AT_GNU_descriptive_type, and the value
 is the DIE of the parallel type. GDB knows how to navigate and decode all
 that for Ada.

 An example of complex aspect is a record field with a length
 depending on another of the record fields, as in the example I posted
 with the original patch submission:

procedure Tryblob (X : Integer) is

      type Blob (Size : integer) is record
         Value : string (1 .. Size);
      end record;

B : Blob (Size => X);

 Blob is a struct with a Size integer field and a Value string field
 of length this.Size. Value is an array of characters here, not a pointer.

 A number of such aspects at least used to be difficult to express in DWARF,
 if at all possible, and we had to find a way for stabs as well, so we came
 up with an encoding scheme that only relies on simple attributes, typically
 field names.

In the case above, for example, we get:

 -       .uleb128 0x6    # (DIE (0x62) DW_TAG_structure_type)
 -       .long   .LASF7  # DW_AT_name: "t__tryblob__blob"
 +       .uleb128 0x8    # (DIE (0x81) DW_TAG_structure_type)
 +       .long   .LASF13 # DW_AT_name: "t__tryblob__blob"
 +       .long   0xb1    # DW_AT_GNU_descriptive_type
 +       .uleb128 0x6    # (DIE (0xb1) DW_TAG_structure_type)
 +       .long   .LASF7  # DW_AT_name: "t__tryblob__blob___XVE"
 +       .uleb128 0x7    # (DIE (0xcb) DW_TAG_member)
 +       .long   .LASF8  # DW_AT_name: "value___XVL"

 The full set of parallel types and encodings we use is described

 This is all controlled by the proposed front-end hook so only
 impacts Ada at this stage.

Why can't dwarf2out generate the desired debug info based on the
primary type?
This has been a long term project for us :)

 Now, there are many cases to account for, some particularily tricky, and
 this still represents a large amount of work in both the compiler (gigi +
 probably dwarf2out), and the debugger AFAIK.

 We have been using the parallel type circuitry for years and decided to
 propose its inclusion on the grounds that it's introduction is pretty light
 on the middle-end side and it makes a real immediate difference for Ada as
 GDB has everything already.


Michael Eager
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

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