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. However, to get there, I had to use my 5.1 gnatmake -g -gnatws macrosub.ads --rts=/path/to/5.2/arm-none-linux-gnueabihf/libada, as if I ran 5.1 gnatmake without that flag, I did not manage to get the wrong value passed/received with LD_LIBRARY_PATH set to any of build-5.2/gcc/ada/rts, build-5.2/arm-none-linux-gnueabihf/libada, build-5.2/arm-none-linux-gnueabihf/libada/adalib (any further suggestions?). [Also I note 'LD_DEBUG=all ./macrosub' does not show libgnat being loaded that way.] With 5.1 gnatmake -g -gnatws macrosub.ads --rts=/path/to/5.2/arm-none-linux-gnueabihf/libada : $ gdb ./macrosub GNU gdb (Ubuntu 7.7-0ubuntu3) 7.7 ....[snip].... Reading symbols from ./macrosub...done. (gdb) break get_line Breakpoint 1 at 0x1aeec: get_line. (4 locations) (gdb) run Starting program: /home/alalaw01/build-5.1.0/gcc/testsuite/ada/acats/support/macrosub BEGINNING MACRO SUBSTITUTIONS. Breakpoint 1, ada.text_io.get_line (item=...) at a-tigeli.adb:41 41 procedure Get_Line (gdb) print item'first $1 = -443273216 (gdb) print item'last $2 = -514850813 (gdb) n 146 FIO.Check_Read_Status (AP (File)); (gdb) n 152 if Item'First > Item'Last then (gdb) print item'first $3 = 1 (gdb) print item'last $4 = 0 (gdb) up #1 0x0001f34c in getsubs.fill_table () at getsubs.adb:122 122 GET_LINE (INFILE1, A_LINE, A_LENGTH); (gdb) print a_line'first $5 = 1 (gdb) print a_line'last $6 = 400 So yes, we have an ABI change; which is not entirely unexpected. So, questions.... (1) Why does LD_LIBRARY_PATH affect your system, not mine (i.e. if this is because my gnatmake is building with static linking, then why). This is maybe the least interesting question so I'm leaving it for now... (2) If/when LD_LIBRARY_PATH does have an effect - as you say, things compiled with host gnatmake, should be run against host libraries, not against target libraries. Otherwise, potentially *any* gcc ABI change can break the build process, right? So I think this is of interest regardless of the ARM AAPCS change, but I will be slightly presumptious and hope that the Adacore folk will pick this up...[CC Eric] (3) Has the ARM AAPCS had an effect that we didn't mean it to? I don't see any evidence so far that this is _necessarily_ the case, but I will look into this, bearing Florian's advice in mind (thanks!)... --Alan