From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9726 invoked by alias); 24 Oct 2014 17:11:28 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 9658 invoked by uid 89); 24 Oct 2014 17:11:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f44.google.com Received: from mail-qa0-f44.google.com (HELO mail-qa0-f44.google.com) (209.85.216.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 24 Oct 2014 17:11:24 +0000 Received: by mail-qa0-f44.google.com with SMTP id w8so1261287qac.3 for ; Fri, 24 Oct 2014 10:11:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pZsgpM+XE5AAKqnjnUMf5jgbNmmdieMv+mNyKTFeBxY=; b=PoAMUqVDVR1E8swdaJ2ISiteydcs5qVAzpzNGBK5GG33aD2mu+xxyV1ZM0m79ZkAJH aKLLJ/Ds6OGHBhS4baaf593eJ0LNEFitAsMlkJCkK8gviUy8Q0Lp7DDCrcLAKHDvcIiX wtSpTV1U4+FO2Cj2NAXXQuBX8EtFENwOEQ/I1L5t6+N4ls3AyhcxgdaimHrH5DGVLnFq AvnCn1F9yO33gC6PHG9KpuU8WM3n/h1llnArQAG0whi4wOxqEjE1d76jen1NHGO9+3Wq dse/NUaJt0v+WasLzdmyPHb6cBy3tzxu3TtqrEseo3RSp/3N44RV3q7OBQd6te52E0Ma cFxg== X-Gm-Message-State: ALoCoQl4kOnzX6hGdL81iwH3a7ir+FwztkS39f4yfkTXBmYiJt3y+8mvpOsc5cDMuAxqI27hYh8a MIME-Version: 1.0 X-Received: by 10.224.97.10 with SMTP id j10mr7776389qan.103.1414170682380; Fri, 24 Oct 2014 10:11:22 -0700 (PDT) Received: by 10.229.93.203 with HTTP; Fri, 24 Oct 2014 10:11:22 -0700 (PDT) In-Reply-To: <87k33px31z.fsf@codesourcery.com> References: <1413853021-4393-1-git-send-email-victor.kamensky@linaro.org> <1413853021-4393-6-git-send-email-victor.kamensky@linaro.org> <87siievw6z.fsf@codesourcery.com> <87k33px31z.fsf@codesourcery.com> Date: Fri, 24 Oct 2014 17:11:00 -0000 Message-ID: Subject: Re: [PATCH 5/5] ARM: asm-source.exp link options in case of armv7b target From: Victor Kamensky To: Yao Qi Cc: Andrew Pinski , "gdb-patches@sourceware.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2014-10/txt/msg00661.txt.bz2 On 24 October 2014 01:52, Yao Qi wrote: > Andrew Pinski 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 (=E9=BD=90=E5=B0=A7)