Message ID | 1413853021-4393-6-git-send-email-victor.kamensky@linaro.org |
---|---|
State | New, archived |
Headers |
Received: (qmail 12864 invoked by alias); 21 Oct 2014 00:57:33 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 12761 invoked by uid 89); 21 Oct 2014 00:57:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f173.google.com Received: from mail-pd0-f173.google.com (HELO mail-pd0-f173.google.com) (209.85.192.173) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 21 Oct 2014 00:57:30 +0000 Received: by mail-pd0-f173.google.com with SMTP id g10so203844pdj.4 for <gdb-patches@sourceware.org>; Mon, 20 Oct 2014 17:57:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=TCB+yKcL14yEo6qrdgQgcwRM9aZ6sNcexVrsDAQxDRk=; b=fY8TYl1b3PYg/VUsuSou0qXS6HRiqTTLyUlr+8rS6Z8/O80VvuCZPhxMBW/02J5hrX kj6k5M6lItA53KJN33pyQ6XCCo3ftz/nF/uXdvcY0wT0nFmgXO63ndTBbzK/gwqCrYSX XRdsS/1AJFjNBaCLpyngzrrF4ZCfzfgJKXDCLNxCOKnApAdNjURYqxCmRsjVWMjhUv6z K78N/FaJ6b2+QYCrsCcWDfobr+NV3TeznOJkTzwcwNSiOxLxeXLahLsPaSVJEj52dNIJ csThwCTs2wwskuertLskDADv1VtOcZ4i/EO9aMNUsBo5Uy2N8aOhNLwnJifM32uLAvar gl+Q== X-Gm-Message-State: ALoCoQmcHpQgiQE3LZlJpxt5XRi0LUy52/eapGOmg7POQwUQWabcDnKpy5GTk2r4eErlvMuJFL1I X-Received: by 10.70.35.72 with SMTP id f8mr7218625pdj.134.1413853048978; Mon, 20 Oct 2014 17:57:28 -0700 (PDT) Received: from kamensky-w530.cisco.com.net ([24.6.79.41]) by mx.google.com with ESMTPSA id g15sm10230692pdm.68.2014.10.20.17.57.27 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Oct 2014 17:57:28 -0700 (PDT) From: Victor Kamensky <victor.kamensky@linaro.org> To: gdb-patches@sourceware.org Cc: victor.kamensky@linaro.org Subject: [PATCH 5/5] ARM: asm-source.exp link options in case of armv7b target Date: Mon, 20 Oct 2014 17:57:01 -0700 Message-Id: <1413853021-4393-6-git-send-email-victor.kamensky@linaro.org> In-Reply-To: <1413853021-4393-1-git-send-email-victor.kamensky@linaro.org> References: <1413853021-4393-1-git-send-email-victor.kamensky@linaro.org> |
Commit Message
Victor Kamensky
Oct. 21, 2014, 12:57 a.m. UTC
gdb.asm/asm-source.exp fails in armv7b case, because it does not pass --be8 option to link, as result instructions in asm-source executable are in big endian order and crash with SIGILL. Solution is to add --be8 option to link command during test creation. --- gdb/testsuite/ChangeLog | 4 ++++ gdb/testsuite/gdb.asm/asm-source.exp | 4 ++++ 2 files changed, 8 insertions(+)
Comments
Victor Kamensky <victor.kamensky@linaro.org> writes: > + "armv7b-*-*" { > + set asm-arch arm > + append link-flags " -be8" > + } We can't tell whether "-be8" is needed from the target triplet. Considering multi-lib, "-be8" is needed for one multilib, but not for the other. Maybe, you can fix your problem by running tests via LDFLAGS_FOR_TARGET, $ make check RUNTESTFLAGS='LDFLAGS_FOR_TARGET=-be8' or you can create your own board file foo.exp, and add set_board_info ldflags "-be8" $ make check RUNTESTFLAGS='--target_board=foo'
Hi Yao, On 23 October 2014 23:05, Yao Qi <yao@codesourcery.com> wrote: > Victor Kamensky <victor.kamensky@linaro.org> writes: > >> + "armv7b-*-*" { >> + set asm-arch arm >> + append link-flags " -be8" >> + } > > We can't tell whether "-be8" is needed from the target triplet. > Considering multi-lib, "-be8" is needed for one multilib, but not > for the other. Any executable/library that runs on big endian V7 *must* be linked with -be8 option. Otherwise it simply won't run. In any other multilib option vfp, neon, etc -be8 must be set. Basically, in big endian case gcc/gas generates data and instructions in big endian format but ARM V7 requires that instruction should be little endian format. It is linker that does instructions byte swap. If -be8 flag is not passed during link while running on ARM V7 big endian target executable with crash with SIGILL. If link happens through gcc, then -be8 always passed for non relocatable code by compiler. In this particular case link happens directly with linker and -be8 is not default, so it is needed. One may argue that -be8 for final executables in ARM V7 BE target should be default even for linker, but it is not the current case ... Also note that you have plenty examples in the same test gdb/testsuite/gdb.asm/asm-source.exp that do very similar things. For example: "powerpc64le-*" { set asm-arch powerpc64le set asm-flags "-a64 -I${srcdir}/${subdir} $obj_include" append link-flags " -m elf64lppc" } Why "-m elf64lppc" is set for powerpc64le target? I suspect by very similar reasons. > Maybe, you can fix your problem by running tests via LDFLAGS_FOR_TARGET, > > $ make check RUNTESTFLAGS='LDFLAGS_FOR_TARGET=-be8' > > or you can create your own board file foo.exp, and add > > set_board_info ldflags "-be8" I don't feel very strong about it, and definitely I can workaround this issue or just ignore the failure. It just seemed that it was very easy to fix. If you are still not convinced by above argument, yes, let's just drop it. Please let me know you final thoughts. We will proceed accordingly. I am fine either way. Thanks, Victor > $ make check RUNTESTFLAGS='--target_board=foo' > > -- > Yao (齐尧)
On Thu, Oct 23, 2014 at 11:35 PM, Victor Kamensky <victor.kamensky@linaro.org> wrote: > Hi Yao, > > On 23 October 2014 23:05, Yao Qi <yao@codesourcery.com> wrote: >> Victor Kamensky <victor.kamensky@linaro.org> writes: >> >>> + "armv7b-*-*" { >>> + set asm-arch arm >>> + append link-flags " -be8" >>> + } >> >> We can't tell whether "-be8" is needed from the target triplet. >> Considering multi-lib, "-be8" is needed for one multilib, but not >> for the other. > > Any executable/library that runs on big endian V7 *must* be linked > with -be8 option. Otherwise it simply won't run. In any other multilib > option vfp, neon, etc -be8 must be set. Basically, in big endian case > gcc/gas generates data and instructions in big endian > format but ARM V7 requires that instruction should be little endian > format. It is linker that does instructions byte swap. If -be8 flag > is not passed during link while running on ARM V7 big endian target > executable with crash with SIGILL. If link happens through gcc, then > -be8 always passed for non relocatable code by compiler. In this > particular case link happens directly with linker and -be8 is not > default, so it is needed. One may argue that -be8 for final > executables in ARM V7 BE target should be default even for > linker, but it is not the current case ... > > Also note that you have plenty examples in the same test > gdb/testsuite/gdb.asm/asm-source.exp > that do very similar things. For example: > > "powerpc64le-*" { > set asm-arch powerpc64le > set asm-flags "-a64 -I${srcdir}/${subdir} $obj_include" > append link-flags " -m elf64lppc" > } > > Why "-m elf64lppc" is set for powerpc64le target? I suspect > by very similar reasons. Yes and no. For PowerPC64 little-endian is Linux only so it will never have a multi-libs that support both little-endian and big-endian. While for arm*-*-*, you can have a bare metal env and that could have a multi-lib for both little and big endian. This is true for MIPS too. Thanks, Andrew Pinski > >> Maybe, you can fix your problem by running tests via LDFLAGS_FOR_TARGET, >> >> $ make check RUNTESTFLAGS='LDFLAGS_FOR_TARGET=-be8' >> >> or you can create your own board file foo.exp, and add >> >> set_board_info ldflags "-be8" > > I don't feel very strong about it, and definitely I can workaround > this issue or just ignore the failure. It just seemed that it was very > easy to fix. > > If you are still not convinced by above argument, yes, > let's just drop it. Please let me know you final thoughts. We > will proceed accordingly. I am fine either way. > > Thanks, > Victor > >> $ make check RUNTESTFLAGS='--target_board=foo' >> >> -- >> Yao (齐尧)
Andrew Pinski <pinskia@gmail.com> writes: >> Any executable/library that runs on big endian V7 *must* be linked >> with -be8 option. Otherwise it simply won't run. In any other multilib >> option vfp, neon, etc -be8 must be set. Basically, in big endian case >> gcc/gas generates data and instructions in big endian >> format but ARM V7 requires that instruction should be little endian >> format. It is linker that does instructions byte swap. If -be8 flag >> is not passed during link while running on ARM V7 big endian target >> executable with crash with SIGILL. If link happens through gcc, then >> -be8 always passed for non relocatable code by compiler. In this >> particular case link happens directly with linker and -be8 is not >> default, so it is needed. One may argue that -be8 for final >> executables in ARM V7 BE target should be default even for >> linker, but it is not the current case ... >> >> Also note that you have plenty examples in the same test >> gdb/testsuite/gdb.asm/asm-source.exp >> that do very similar things. For example: >> >> "powerpc64le-*" { >> set asm-arch powerpc64le >> set asm-flags "-a64 -I${srcdir}/${subdir} $obj_include" >> append link-flags " -m elf64lppc" >> } >> >> Why "-m elf64lppc" is set for powerpc64le target? I suspect >> by very similar reasons. > > > Yes and no. For PowerPC64 little-endian is Linux only so it will > never have a multi-libs that support both little-endian and > big-endian. While for arm*-*-*, you can have a bare metal env and > that could have a multi-lib for both little and big endian. Andrew is right. We can have a arm-linux-gnueabi toolchain which has multilibs for the combination of {le, be} x {armv7, armv6, armv5}, and this test still fails on armv7 be multilib.
On 24 October 2014 01:52, Yao Qi <yao@codesourcery.com> wrote: > Andrew Pinski <pinskia@gmail.com> writes: > >>> Any executable/library that runs on big endian V7 *must* be linked >>> with -be8 option. Otherwise it simply won't run. In any other multilib >>> option vfp, neon, etc -be8 must be set. Basically, in big endian case >>> gcc/gas generates data and instructions in big endian >>> format but ARM V7 requires that instruction should be little endian >>> format. It is linker that does instructions byte swap. If -be8 flag >>> is not passed during link while running on ARM V7 big endian target >>> executable with crash with SIGILL. If link happens through gcc, then >>> -be8 always passed for non relocatable code by compiler. In this >>> particular case link happens directly with linker and -be8 is not >>> default, so it is needed. One may argue that -be8 for final >>> executables in ARM V7 BE target should be default even for >>> linker, but it is not the current case ... >>> >>> Also note that you have plenty examples in the same test >>> gdb/testsuite/gdb.asm/asm-source.exp >>> that do very similar things. For example: >>> >>> "powerpc64le-*" { >>> set asm-arch powerpc64le >>> set asm-flags "-a64 -I${srcdir}/${subdir} $obj_include" >>> append link-flags " -m elf64lppc" >>> } >>> >>> Why "-m elf64lppc" is set for powerpc64le target? I suspect >>> by very similar reasons. >> >> >> Yes and no. For PowerPC64 little-endian is Linux only so it will >> never have a multi-libs that support both little-endian and >> big-endian. While for arm*-*-*, you can have a bare metal env and >> that could have a multi-lib for both little and big endian. > > Andrew is right. We can have a arm-linux-gnueabi toolchain which has > multilibs for the combination of {le, be} x {armv7, armv6, armv5}, and > this test still fails on armv7 be multilib. I am not sure that I follow your argument, Your point that for arm-linux-gnueab that has big endian multilib test will fail, and because of that we want it to keep failing on armv7b-unknown-linux-gnueabihf target? The fix I suggested will be activate only if target triplet starts with 'armv7b'. The situation when target name starts with 'armv7b' and has little endian multilib support seems very hypothetical to me. In case of arm-linux-gnueabi with big endian multilib pretty much all tests will fail, unless caller will not specify correct compile/link option (i.e compile -mbig-endian -Wl,--be8, link --be8, etc). OK, it seems that the patch causes too much controversy, I am going to drop it. I'll re-post series without it with final version of other 3 patches, the one that I believe approved by you. And I will wait for few days for additional feedback. Thanks, Victor > -- > Yao (齐尧)
diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog index b7cc1c6..1d5fefa 100644 --- a/gdb/testsuite/ChangeLog +++ b/gdb/testsuite/ChangeLog @@ -1,3 +1,7 @@ +2014-10-13 Victor Kamensky <victor.kamensky@linaro.org> + + * gdb.asm/asm-source.exp: add armv7b case for target. + 2014-09-30 Yao Qi <yao@codesourcery.com> * lib/prelink-support.exp (build_executable_own_libs): Error if diff --git a/gdb/testsuite/gdb.asm/asm-source.exp b/gdb/testsuite/gdb.asm/asm-source.exp index fa4585c..153bc50 100644 --- a/gdb/testsuite/gdb.asm/asm-source.exp +++ b/gdb/testsuite/gdb.asm/asm-source.exp @@ -37,6 +37,10 @@ switch -glob -- [istarget] { set asm-flags "-no-mdebug -I${srcdir}/${subdir} $obj_include" set debug-flags "-gdwarf-2" } + "armv7b-*-*" { + set asm-arch arm + append link-flags " -be8" + } "arm*-*-*" { set asm-arch arm }