[PATCH] DWARFv5 DW_TAG_aligned_type.

Mark Wielaard mjw@redhat.com
Mon Sep 29 15:17:00 GMT 2014

Hi Joel,

My apologies it took so long before I made time to look at your example.

On Wed, 2014-07-30 at 09:59 -0700, Joel Brobecker wrote:
> > 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

Thanks. I used
https://gcc.gnu.org/onlinedocs/gnat_ugn_unw/Running-a-Program-with-Multiple-Units.html to play a bit with it and get something I could inspect under GDB.

I think I see now what you mean with not having alignment needing to be
stricter for sub types in Ada.

    type Another_Integer is new My_Integer;
    for Another_Integer'Alignment use 8;

    type Your_Integer is new Another_Integer;
    for Your_Integer'Alignment use 4;

    C : Character;
    I : My_Integer;
    C2 : Character;
    I2 : Another_Integer;
    C3 : Character;
    I3 : Your_Integer;

Adding some variables of different subtypes shows the compiler uses the
actual user defined aligned, not the the strictest alignment possible
according to the type hierarchy when multiple are defined. On the other
hand, in Ada you don't seem to be able to add the alignment aspect for a
specific type multiple times as you can in C. But at least usage of
"strictest alignment" wording can be a little confusing in this case.

Something that does surprise me is that ptype in gdb seems to always
just give the valid subrange of the variables I, I2, I3, not their
actual type.

(gdb) ptype P.I3
type = range -2147483648 .. 2147483647

While my changes for C types were so that ptype would produce a type
that you could in theory just pass into the compiler again to get you
the same thing. Is the above a deliberate choice for Ada? Hmmm, it seems
the above "type Another_Integer is new My_Integer" construct does not
result in any DWARF output that would make it possible to say
Another_Integer is a subtype of My_Integer?

> 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?

In my example above do see a PAD for some (the first) variable type, but
not others. Those just point directly to the named DW_TAG_subrange_type.
I think I would expect it to be on the (named) subrange_type either
inside or outside the "PAD" (what does that stand for BTW?) struct.



More information about the Gdb-patches mailing list