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]

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


Hi Jason,

Any further opinion or question on this topic ?

Thanks in advance,

Olivier

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
>  in exp_dbug.ads.
> 
>  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.
> 
>  Olivier
> 
> 
> 
>   
> 


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