This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] DWARFv5 DW_TAG_aligned_type.
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Mark Wielaard <mjw at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Tom Tromey <tromey at redhat dot com>
- Date: Wed, 30 Jul 2014 09:59:34 -0700
- Subject: Re: [PATCH] DWARFv5 DW_TAG_aligned_type.
- Authentication-results: sourceware.org; auth=none
- References: <1404944457-4500-1-git-send-email-mjw at redhat dot com> <20140711144227 dot GB4888 at adacore dot com> <1405635556 dot 17759 dot 205 dot camel at bordewijk dot wildebeest dot org> <1405635906 dot 17759 dot 210 dot camel at bordewijk dot wildebeest dot org>
Hi Mark,
> Forgot to ask...
>
> On Fri, 2014-07-18 at 00:19 +0200, Mark Wielaard wrote:
> > On Fri, 2014-07-11 at 07:42 -0700, Joel Brobecker wrote:
> > > My only question is regarding the checks for alignments to be stricter
> > > than the alignment of their base types. Why are they needed? I am asking
> > > because, in Ada, it is allowed to be specifying an alignment which is
> > > less strict than the standard alignment. We can ask for byte-aligned
> > > integers, for instance.
>
> Could you post an example Ada source code example so I can test a bit
> how my gcc and gdb patches interact for an user aligned Ada type?
Here it is (credits to Eric Botcazou):
package P is
type My_Integer is new Integer;
for My_Integer'Alignment use 1;
C : Character;
I : My_Integer;
end P;
Save the code in a file called p.ads, and then compile it using:
% gcc -c -g p.ads
Variable "C" is just there to prevent variable "I" from being
default-aligned by accident.
If you look at the debugging info, you'll find that our variable
is called "p__i". The alignment is handled via putting it inside
a ___PAD struct as a component called "F". Eg:
.uleb128 0x6 # (DIE (0x70) DW_TAG_variable)
.long .LASF1 # DW_AT_name: "p__i"
.long 0x1d # DW_AT_type
Following the type of that variable gives us:
.uleb128 0x2 # (DIE (0x1d) DW_TAG_structure_type)
.long .LASF5 # DW_AT_name: "p__my_integer___PAD"
[...]
.uleb128 0x3 # (DIE (0x29) DW_TAG_member)
.ascii "F\0" # DW_AT_name
.long 0x38 # DW_AT_type
Following then the type of member "F" yields a subrange type:
.uleb128 0x4 # (DIE (0x38) DW_TAG_subrange_type)
.long 0x80000000 # DW_AT_lower_bound
.long 0x7fffffff # DW_AT_upper_bound
.long .LASF6 # DW_AT_name: "p__my_integer"
.long 0x4b # DW_AT_type
.byte 0x1 # DW_AT_artificial
... which points to the integer base type:
.uleb128 0x5 # (DIE (0x4b) DW_TAG_base_type)
.byte 0x4 # DW_AT_byte_size
.byte 0x5 # DW_AT_encoding
.long .LASF7 # DW_AT_name: "p__Tmy_integerB"
.byte 0x1 # DW_AT_artificial
Ideally, it'd be better if variable I was described without the PAD
wrapper. We may be headed towards that in the long run, not sure.
But, in the meantime, I think the logical location for adding the
alignment info would probably be the PAD struct?
--
Joel