From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113463 invoked by alias); 27 Aug 2015 09:42:08 -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 113451 invoked by uid 89); 27 Aug 2015 09:42:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,KAM_STOCKGEN,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 09:42:04 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56856) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ZUth3-0002Pv-W1 for gcc-patches@gnu.org; Thu, 27 Aug 2015 05:42:02 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUth0-00046t-TI for gcc-patches@gnu.org; Thu, 27 Aug 2015 05:42:01 -0400 Received: from eu-smtp-delivery-143.mimecast.com ([207.82.80.143]:28310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUth0-000460-JT for gcc-patches@gnu.org; Thu, 27 Aug 2015 05:41:58 -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-30-a55_fEOTRWe9sHfSCciE1g-1; Thu, 27 Aug 2015 10:41:57 +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 10:41:57 +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 09:53:00 -0000 In-reply-to: Message-ID: MIME-Version: 1.0 X-MC-Unique: a55_fEOTRWe9sHfSCciE1g-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/msg01678.txt.bz2 Christophe Lyon writes: > On 27 August 2015 at 10:35, Jiong Wang wrote: >> >> Christophe Lyon writes: >> >>> On 19 August 2015 at 16:21, Jiong Wang wrote: >>>> >>>> Marcus Shawcroft writes: >>>> >>>>> On 21 May 2015 at 17:49, Jiong Wang wrote: >>>>> >>>>>> 2015-05-14 Jiong Wang >>>>>> gcc/ >>>>>> * config/aarch64/aarch64.c (aarch64_print_operand): Support tls_si= ze. >>>>>> * config/aarch64/aarch64.md (tlsle): Choose proper instruction >>>>>> sequences. >>>>>> (tlsle_): New define_insn. >>>>>> (tlsle_movsym_): Ditto. >>>>>> * config/aarch64/constraints.md (Uta): New constraint. >>>>>> (Utb): Ditto. >>>>>> (Utc): Ditto. >>>>>> (Utd): Ditto. >>>>>> >>>>>> gcc/testsuite/ >>>>>> * gcc.target/aarch64/tlsle.c: New test source. >>>>>> * gcc.target/aarch64/tlsle12.c: New testcase. >>>>>> * gcc.target/aarch64/tlsle24.c: New testcase. >>>>>> * gcc.target/aarch64/tlsle32.c: New testcase. >>>>>> >>>>> >>>>> >>>>> case SYMBOL_TLSLE: >>>>> - asm_fprintf (asm_out_file, ":tprel_lo12_nc:"); >>>>> + if (aarch64_tls_size <=3D 12) >>>>> + /* Make sure TLS offset fit into 12bit. */ >>>>> + asm_fprintf (asm_out_file, ":tprel_lo12:"); >>>>> + else >>>>> + asm_fprintf (asm_out_file, ":tprel_lo12_nc:"); >>>>> break; >>>>> >>>>> Use the existing classify_symbol mechanism we use throughout the >>>>> aarch64 backend. Specifically rename SYMBOL_TLSLE as SYMBOL_TLSLE24 >>>>> and introduce the 3 missing flavours then use the symbol >>>>> classification to control behaviour such as this modifier selection. >>>> >>>> Done. >>>> >>>> classified TLS symbol into the following sub-types according to the va= lue of tls size. >>>> >>>> SYMBOL_TLSLE12 >>>> SYMBOL_TLSLE24 >>>> SYMBOL_TLSLE32 >>>> SYMBOL_TLSLE48 >>>> >>>> And On AArch64, instruction sequence for TLS LE under -mtls-size=3D32 = will >>>> utilize the relocation modifier "tprel_g0_nc" together with MOVK, it's >>>> only supported in binutils since 2015-03-04 as PR gas/17843. So I >>>> adjusted tlsle32.c to make it robust by detecting whether there is such >>>> binutils support. >>>> >>> >>> Hi, >>> >>> I'm (still) using binutils-2.25, and I can see that 2 of these new >>> tests (tlsle12_1.c and tlsle24_1.c) fail at execution time on >>> aarch64*-none-elf targets. >> >> Christophe, >> >> 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 environment. >> >> 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. --=20 Regards, Jiong