Re: [PATCH 1/2][ARM] PR/65956 AAPCS update for alignment attribute

[Alan Lawrence <alan dot lawrence at arm dot com>]

On 26 November 2015 at 14:00, Alan Lawrence <alan.lawrence@arm.com> wrote:
> On 6 November 2015 at 16:59, Jakub Jelinek <jakub@redhat.com> wrote:
>>
>> In any case, to manually reproduce, compile
>> gnatmake -g -gnatws macrosub.adb
>> with GCC 5.1.1 (before the ARM changes) and then try to run that process against
>> GCC 5.2.1 (after the ARM changes) libgnat-5.so, which is what make check
>> does (it uses host_gnatmake to compile the support stuff, so ideally the
>> processes built by host gcc/gnatmake should not be run with the
>> LD_LIBRARY_PATH=$ADA_INCLUDE_PATH:$BASE:$LD_LIBRARY_PATH
>> in the environment, and others should).
>> In macrosub in particular, the problem is in:
>>           WHILE NOT END_OF_FILE (INFILE1) LOOP
>>                GET_LINE (INFILE1, A_LINE, A_LENGTH);
>> in FILL_TABLE, where A_LINE'First is 0 and A_LINE'Last is 400 (if I remember
>> right), but if you step into GET_LINE compiled by GCC 5.2.1, Item'First
>> and Item'Last don't match that.
>
> Ok, I see the mismatch now.

The type affected in Jakub's case here is an Ada String, which looks like this:

<record_type 0xf7569720 string___XUP sizes-gimplified asm_written
visited type_0 DI
    size <integer_cst 0xf7469210 type <integer_type 0xf7474060
bitsizetype> constant 64>
    unit size <integer_cst 0xf7469228 type <integer_type 0xf7474000
sizetype> constant 8>
    align 64 symtab -151604912 alias set -1 canonical type 0xf7569720
    fields <field_decl 0xf7569c60 P_ARRAY
        type <pointer_type 0xf756a2a0 type <array_type 0xf756a0c0 string___XUA>
            asm_written unsigned SI
            size <integer_cst 0xf74691b0 constant 32>
            unit size <integer_cst 0xf74691c8 constant 4>
            align 32 symtab -151604672 alias set -1 canonical type 0xf756a2a0>
        unsigned nonaddressable SI file <built-in> line 0 col 0 size
<integer_cst 0xf74691b0 32> unit size <integer_cst 0xf74691c8 4>
        align 32 offset_align 64
        offset <integer_cst 0xf74691e0 constant 0>
        bit offset <integer_cst 0xf7469240 constant 0> context
<record_type 0xf7569720 string___XUP>
        chain <field_decl 0xf7569cc0 P_BOUNDS type <pointer_type 0xf7569600>
            visited unsigned nonaddressable SI file <built-in> line 0
col 0 size <integer_cst 0xf74691b0 32> unit size <integer_cst
0xf74691c8 4>
            align 32 offset_align 64 offset <integer_cst 0xf74691e0 0>
bit offset <integer_cst 0xf74691b0 32> context <record_type 0xf7569720
string___XUP>>> context <translation_unit_decl 0xf77ea0a0 D.2757>
    unconstrained array <unconstrained_array_type 0xf7569c00 string
type <record_type 0xf7569720 string___XUP>
        BLK
        align 8 symtab 0 alias set -1 canonical type 0xf7569c00
context <translation_unit_decl 0xf77ea0a0 D.2757>
        pointer_to_this <record_type 0xf7569720 string___XUP>
reference_to_this <record_type 0xf7569720 string___XUP> chain
<type_decl 0xf756a660 string>>
    chain <type_decl 0xf7569d20 string___XUP>>

i.e. a 64-bit DImode struct, with alignment set to 64, containing
P_ARRAY a 32-bit pointer with alignment 32, and P_BOUNDS a 32-bit pointer
with alignment 32, pointing to a record (of size 64, alignment 32, containing
two 32-bit ints LB0 and UB0).

AFAICT, in the fill_table/get_line case, the first parameter to
get_line is a file, a simple pointer; then we have a string. So

*fill_table (compiled with 5.1, doubleword aligned) should pass the
string P_ARRAY in r2 and P_BOUNDS in r3.

0x1f334 <getsubs__fill_table+184>       movt   r3, #2
0x1f338 <getsubs__fill_table+188>       str    r3, [r11, #-504]        ; 0x
0x1f33c <getsubs__fill_table+192>       sub    r3, r11, #508   ; 0x1fc
0x1f340 <getsubs__fill_table+196>       ldrd   r2, [r3]
0x1f344 <getsubs__fill_table+200>       mov    r0, r1
0x1f348 <getsubs__fill_table+204>       bl     0x1aee4 <ada__text_io__get_line

looks plausible.

*get_line (compiled with 5.2, new AAPCS), should read P_ARRAY from r1,
and P_BOUNDS from r2. So the received P_BOUNDS is thus the passed
P_ARRAY, which in my example comes out as (1,0); the received P_ARRAY
is probably totally bogus.

And indeed the assembler for get_line seems to use r2 as a pointer to
a struct containing first & last.

So, I'm not familiar with Ada 'fat pointers' but if that is one -
well, it's a record, with an alignment that the 'new' AAPCS now
ignores, so yes the ABI has changed between gcc 5.1 and 5.2, rather
more significantly for Ada than for C.

Thoughts?


--Alan