From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101098 invoked by alias); 27 Aug 2015 13:45:28 -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 101054 invoked by uid 89); 27 Aug 2015 13:45:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 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:45:20 +0000 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53598) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ZUxUT-0001GT-TC for gcc-patches@gnu.org; Thu, 27 Aug 2015 09:45:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZUxUP-00024Q-Ci for gcc-patches@gnu.org; Thu, 27 Aug 2015 09:45:17 -0400 Received: from mail-qk0-f180.google.com ([209.85.220.180]:34767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZUxUP-00024M-8G for gcc-patches@gnu.org; Thu, 27 Aug 2015 09:45:13 -0400 Received: by qkfh127 with SMTP id h127so10507604qkf.1 for ; Thu, 27 Aug 2015 06:45:13 -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; bh=pbG04Kk6RArNXjzJm+jATqMVm21TZ+3CccWz2pJG9fs=; b=Xi/vnZho9Beg3Lu3MDl8jXpy0DY+wfR1VdiKXo5UB5l9PZIjL68Wd7jrW194IzyU4t 8dVXfYSRWzsr8czMtjkDf6yZTTqZ8UpGNMtm0OlgaKNVGpsTuvVJln5ZWD9eWAygC4C0 iIfOZNDrntKdTMhyY/ADRFR1HIb01FdKqsGiWhpOcqwPKnqQOJEeVXaNPDqpnorAhroR Gjou5EPm2mV9JlGoQSuNEktGJy9LmoMydgZ3eQ+5rWVXjze8TuBN2XzFNGsBmyyFS/th Ze1PXj9dugEQQn3YBO9EuZjV0YPL2VtM4VVr5+8F7zG9zpODdcp9aj+eYYsgBDphQsTW VXlA== X-Gm-Message-State: ALoCoQm9mqTNIxbjG9/j3JUWlUPkLctSmht5BgFDzunRdFma0LmZNXLqwOk+D88pGkjhnYEcUqXx MIME-Version: 1.0 X-Received: by 10.55.198.92 with SMTP id b89mr6528533qkj.102.1440683112813; Thu, 27 Aug 2015 06:45:12 -0700 (PDT) Received: by 10.140.96.226 with HTTP; Thu, 27 Aug 2015 06:45:12 -0700 (PDT) In-Reply-To: References: Date: Thu, 27 Aug 2015 13:45:00 -0000 Message-ID: Subject: Re: [AArch64][TLSLE][3/3] Implement local executable mode for all memory model From: Christophe Lyon To: Jiong Wang Cc: Marcus Shawcroft , gcc-patches Content-Type: text/plain; charset=UTF-8 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 209.85.220.180 X-IsSubscribed: yes X-SW-Source: 2015-08/txt/msg01704.txt.bz2 On 27 August 2015 at 15:35, Jiong Wang wrote: > > 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 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. >>> >>> 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 emutls > ... > 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. > Thanks for looking at that. Indeed, I do not pass --disable-tls, I relied on configure to do-the-right-thing. I'll make that change. > Above solution is only wrong if your bare-metal do support "tp" based > native tls mechanism which I think largely not. I'm using the classical newlib. > >> >>> 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 >>> > > -- > Regards, > Jiong >