From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 130062 invoked by alias); 26 Nov 2015 14:00:50 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 129961 invoked by uid 89); 26 Nov 2015 14:00:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-oi0-f43.google.com Received: from mail-oi0-f43.google.com (HELO mail-oi0-f43.google.com) (209.85.218.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Thu, 26 Nov 2015 14:00:46 +0000 Received: by oixx65 with SMTP id x65so47390484oix.0 for ; Thu, 26 Nov 2015 06:00:44 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.202.98.86 with SMTP id w83mr27040122oib.135.1448546444697; Thu, 26 Nov 2015 06:00:44 -0800 (PST) Received: by 10.202.95.213 with HTTP; Thu, 26 Nov 2015 06:00:44 -0800 (PST) In-Reply-To: <20151106165959.GF5675@tucnak.redhat.com> References: <5596A98A.7080500@arm.com> <5596B421.2030806@foss.arm.com> <2568443.T54aGJxWO1@polaris> <559A5FD1.3040102@arm.com> <559A8F51.80407@foss.arm.com> <559AAF0B.7080405@arm.com> <20151104131351.GE478@tucnak.redhat.com> <563CD9C2.6090603@arm.com> <20151106165959.GF5675@tucnak.redhat.com> Date: Thu, 26 Nov 2015 14:05:00 -0000 Message-ID: Subject: Re: [PATCH 1/2][ARM] PR/65956 AAPCS update for alignment attribute From: Alan Lawrence To: Jakub Jelinek Cc: Ramana Radhakrishnan , Richard Earnshaw , "gcc-patches@gcc.gnu.org" , fweimer@redhat.com, eric botcazou Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg03235.txt.bz2 On 6 November 2015 at 16:59, Jakub Jelinek 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