From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8350 invoked by alias); 27 Aug 2015 13:35:40 -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 8332 invoked by uid 89); 27 Aug 2015 13:35:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 27 Aug 2015 13:35:38 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:49484) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ZUxL6-0000F0-7e for gcc-patches@gnu.org; Thu, 27 Aug 2015 09:35:36 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUxL0-00055F-IE for gcc-patches@gnu.org; Thu, 27 Aug 2015 09:35:35 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:37349) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUxL0-00054r-9f for gcc-patches@gnu.org; Thu, 27 Aug 2015 09:35:30 -0400 Received: from cam-owa1.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-32-Qd3uXzBBRGC_tp-XiD7p5g-1; Thu, 27 Aug 2015 14:35:29 +0100 Received: from e104437-lin ([10.1.2.79]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 27 Aug 2015 14:35:28 +0100 References: From: Jiong Wang To: Christophe Lyon Cc: Marcus Shawcroft , gcc-patches Subject: Re: [AArch64][TLSLE][3/3] Implement local executable mode for all memory model Date: Thu, 27 Aug 2015 13:36:00 -0000 In-reply-to: Message-ID: MIME-Version: 1.0 X-MC-Unique: Qd3uXzBBRGC_tp-XiD7p5g-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 207.82.80.143 X-SW-Source: 2015-08/txt/msg01698.txt.bz2 Christophe Lyon writes: > On 27 August 2015 at 12:03, Jiong Wang wrote: >> >> Jiong Wang writes: >>>>> >>>>> Those relocation types required by tls-size 12 & 24 are supported by >>>>> binutils-2.25 already, and you have passed compilation and failed at >>>>> exectuion, so there do have something wrong I guess. >>>>> >>>>> Either the generated instruction sequence or the bare-metal environme= nt. >>>>> >>>>> One thing strange to me is those testcases are guarded by: >>>>> >>>>> /* { dg-require-effective-target tls_native } */ >>>>> >>>>> while for bare-metal environment, normally you don't have tls_native >>>>> support right? then these testcases should have been marked as >>>>> unsupported otherwise they will generate native tls instruction >>>>> sequences while the bare-metal runtime environment may don't support >>>>> initialize tp register etc, thus caused the exectuion error. >>>>> >>>>> Could you please double check this? thanks >>>>> >>>> >>>> Well, the "tls_native" check passes (there is no "emutls" string in >>>> the generated assembly). >>>> This BTW, does not involve the binutils, since it only check the >>>> assembly output. >>>> >>>> Could it be a configure error instead? (where GCC wouldn't notice that >>>> it shouldn't generate such relocations) >>> >>> to me, it's more like this. native tls is enabled on a no such support >>> platform. >>> >>> I am trying to setup a bare-metal environment for reproducing. I was >>> testing on linux environment. >> >> Finished test on my local aarch64-none-elf bare-metal. they are marked >> as unsupported correctly. gcc is doing correct configuration on my >> environment. looks like somehow gcc is doing wrong tls enable on your >> bare-metal platform. >> > I checked libgcc's configure output and it answers "no" to the > question "whether the thread-local storage support is from emutls" > > What is the result in your case? > > And before that 'assembler supports thread-local storage' is yes, too. configure:4849: checking whether the target assembler supports thread-local= storage ... configure:4867: result: yes configure:4877: checking whether the thread-local storage support is from e= mutls ... configure:4898: result: yes That's my log which means native tls disabled as we are using emutls. A double check shows my bare-metal environment is passing --disable-tls explicitly when configuring gcc. A further look at the gcc code shows gcc decides whether to use native tls or emultls based on targetm.have_tls which is assigned to the value HAVE_AS_TLS. And HAVE_AS_TLS is defined during configure by simply assemble a .s includs some simple instruction sequences contains tls specific stuff. So gcc is making the decision purely on static check, this make sense to me, as it's hard or impossible to make runtime check because you only have binutils that time as toolchain build steps is normally binutils->gcc->libc->g++. I think you need to pass "--disable-tls" to your bare-metal gcc configuration, as gcc do needs user's help here as it doesn't understand runtime features. Above solution is only wrong if your bare-metal do support "tp" based native tls mechanism which I think largely not. > >> UNSUPPORTED: gcc.target/aarch64/tlsdesc_hoist.c >> UNSUPPORTED: gcc.target/aarch64/tlsle12_1.c >> UNSUPPORTED: gcc.target/aarch64/tlsle24_1.c >> UNSUPPORTED: gcc.target/aarch64/tlsle32_1.c >> -- >> Regards, >> Jiong >> --=20 Regards, Jiong