On 26 November 2015 at 14:00, Alan Lawrence <alan.lawre...@arm.com> wrote:
> On 6 November 2015 at 16:59, Jakub Jelinek <ja...@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
