From: Victor Kamensky <victor.kamensky@linaro.org>
To: Yao Qi <yao@codesourcery.com>
Cc: Andrew Pinski <pinskia@gmail.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: Re: [PATCH 5/5] ARM: asm-source.exp link options in case of armv7b target
Date: Fri, 24 Oct 2014 17:11:00 -0000 [thread overview]
Message-ID: <CAA3XUr1U=TdwDZMKQK-QrDaYZ6aAfB+8SFAYizDNzq1kBmZ_gg@mail.gmail.com> (raw)
In-Reply-To: <87k33px31z.fsf@codesourcery.com>
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 (齐尧)
next prev parent reply other threads:[~2014-10-24 17:11 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-21 0:57 [PATCH 0/5] arm: set of big endian related fixes for armeb (v7) Victor Kamensky
2014-10-21 0:57 ` [PATCH 5/5] ARM: asm-source.exp link options in case of armv7b target Victor Kamensky
2014-10-24 6:10 ` Yao Qi
2014-10-24 6:35 ` Victor Kamensky
2014-10-24 6:38 ` Andrew Pinski
2014-10-24 8:57 ` Yao Qi
2014-10-24 17:11 ` Victor Kamensky [this message]
2014-10-21 0:57 ` [PATCH 4/5] ARM: read_pieced_value do big endian processing only in case of valid gdb_regnum Victor Kamensky
2014-10-22 9:31 ` Yao Qi
2014-10-22 15:27 ` Victor Kamensky
2014-10-23 3:22 ` Yao Qi
2014-10-23 5:43 ` Victor Kamensky
2014-10-23 6:24 ` Yao Qi
2014-10-21 0:57 ` [PATCH 3/5] ARM: arm_breakpoint should be little endian form in case for arm BE8 Victor Kamensky
2014-10-21 8:13 ` Yao Qi
2014-10-21 0:57 ` [PATCH 1/5] ARM: plt_size functions need to read instructions in right byte order Victor Kamensky
2014-10-21 0:57 ` [PATCH 2/5] ARM: extract_arm_insn function need to read instrs correctly in be8 case Victor Kamensky
2014-10-21 7:58 ` Yao Qi
2014-10-21 8:04 ` Yao Qi
2014-10-21 14:45 ` Victor Kamensky
2014-10-24 12:20 ` gdb/CONTRIBUTE Pedro Alves
2014-10-24 17:36 ` gdb/CONTRIBUTE Victor Kamensky
2014-10-21 1:12 ` [PATCH 0/5] arm: set of big endian related fixes for armeb (v7) Andrew Pinski
2014-10-21 5:22 ` Victor Kamensky
2014-10-21 7:39 ` Yao Qi
2014-10-22 5:39 ` Victor Kamensky
2014-10-22 9:36 ` Yao Qi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAA3XUr1U=TdwDZMKQK-QrDaYZ6aAfB+8SFAYizDNzq1kBmZ_gg@mail.gmail.com' \
--to=victor.kamensky@linaro.org \
--cc=gdb-patches@sourceware.org \
--cc=pinskia@gmail.com \
--cc=yao@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox