From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 101011 invoked by alias); 20 May 2019 15:59:33 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 100995 invoked by uid 89); 20 May 2019 15:59:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*f:sk:f107b86, H*i:sk:f107b86, HX-Spam-Relays-External:ESMTPA X-HELO: mail-vs1-f54.google.com Received: from mail-vs1-f54.google.com (HELO mail-vs1-f54.google.com) (209.85.217.54) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 May 2019 15:59:32 +0000 Received: by mail-vs1-f54.google.com with SMTP id l20so9237271vsp.3 for ; Mon, 20 May 2019 08:59:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=pMGaGeoQ2WIXeMy5eDWH3PEoa3pCQbvNRv/SE2JDe9k=; b=bGPBKA4Lxp2AA8lSsIE2Z0tlchBXalvYx4SVlvZS2LqAENOHrHe4AB9vIytNHts+Ez PZ4fRyynB9LAzz1BGUlJ3Yhp9Fw0pxYLLLJx2hQFUIHvruoeEiuWl5wjCvrvqAkASWFf +0MBdAvOsplApKz7IuN2BfzFPqvQ++CzzqphpOwkP1wciGatwM7QASOPCyeef3IMnBFe BQwqmb/KO+seOv0KMkBcXVr7K4ZbUsFIH5M/JW0vKf7+iinVbhXWOIp1ImNA1eKNFOSZ BS+2G+3SQQ64VG+VJp5xOzs1S1z2lx9XzL+2aaTvV/ZBpUx87ixpsXmdb00pEbUMAWRE RgZQ== Return-Path: Received: from zooty (c-65-34-205-113.hsd1.fl.comcast.net. [65.34.205.113]) by smtp.gmail.com with ESMTPSA id p185sm4064475vkd.40.2019.05.20.08.59.29 (version=TLS1_3 cipher=AEAD-AES256-GCM-SHA384 bits=256/256); Mon, 20 May 2019 08:59:29 -0700 (PDT) Received: from zooty (localhost [127.0.0.1]) (Authenticated sender: tom) by zooty.my.lan (Postfix) with ESMTPA id 1B3C71416F2; Mon, 20 May 2019 11:59:28 -0400 (EDT) Date: Mon, 20 May 2019 15:59:00 -0000 From: Tom Horsley To: Szabolcs Nagy Cc: "gcc@gcc.gnu.org" , nd Subject: Re: aarch64 TLS optimizations? Message-ID: <20190520115927.09c41e6c@zooty> In-Reply-To: References: <20190517095110.5bd041d6@tomh> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2019-05/txt/msg00163.txt.bz2 On Mon, 20 May 2019 15:43:53 +0000 Szabolcs Nagy wrote: > you can verify that 0x152000 + 3608 == 0x152e18 is > indeed a GOT entry (falls into .got) and there is a > > 0000000000152e18 R_AARCH64_TLS_TPREL64 *ABS*+0x0000000000000010 There are a couple of other TLS variables in malloc, and I suspect this is one of them, where it is actually looking at tcache_shutting_down (verified with debug info and disassembly), it is simply using the tpidr_el0 value still laying around in the register from the 1st TLS reference and loading tcache_shutting_down from an offset which appears for all the world to simply be hard coded, no GOT reference involved. I suppose at some point I'll be forced to understand how to build glibc from the ubuntu source package so I can see exactly what options and ifdefs are used and check the relocations in the malloc.o file from before it is incorporated with libc.so