Re: [PATCH] DWARFv5 DW_TAG_aligned_type.

[Joel Brobecker <brobecker@adacore.com>]

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