This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PING*4] add support for dwarf AT_GNU_descriptive_type
- From: Olivier Hainque <hainque at adacore dot com>
- To: Jason Merrill <jason at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org, brobecker at adacore dot com, guitton at adacore dot com, hainque at adacore dot com
- Date: Tue, 9 Nov 2010 12:19:13 +0100
- Subject: Re: [PING*4] add support for dwarf AT_GNU_descriptive_type
- References: <20100902143849.GA23684@cardhu.act-europe.fr> <20101018080705.GB23465@cardhu.act-europe.fr> <4CC46270.3030200@redhat.com> <20101026084817.GA30044@cardhu.act-europe.fr>
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
>
>
>
>
>