From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2837 invoked by alias); 13 Aug 2007 17:27:09 -0000 Received: (qmail 2704 invoked by uid 22791); 13 Aug 2007 17:27:08 -0000 X-Spam-Check-By: sourceware.org Received: from alnrmhc13.comcast.net (HELO alnrmhc13.comcast.net) (204.127.225.93) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 13 Aug 2007 17:27:00 +0000 Received: from lucon.org ([24.6.230.138]) by comcast.net (alnrmhc13) with ESMTP id <20070813172657b1300ed6qce>; Mon, 13 Aug 2007 17:26:58 +0000 Received: by lucon.org (Postfix, from userid 500) id 11654F8243; Mon, 13 Aug 2007 10:26:57 -0700 (PDT) Date: Mon, 13 Aug 2007 17:27:00 -0000 From: "H.J. Lu" To: binutils@sources.redhat.com, gcc@gcc.gnu.org, GNU C Library Subject: Why does __tls_get_addr call require @PLT for global-dynamic without -fpic? Message-ID: <20070813172657.GA17584@lucon.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.14 (2007-02-12) Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00193.txt.bz2 Is there a particular reason for x86 and x86-64 global-dynamic TLS model to require @PLT when calling __tls_get_addr when PIC isn't required? See http://sources.redhat.com/bugzilla/show_bug.cgi?id=4918 Right now, gcc doesn't generate PLT when calling __tls_get_addr without -fpic. Assert in x86/x86-64 linkers fail because of it. The only thing I can think of is it is used to make sure that it is a call instruction. I may have missed something. If not, I'd like to change it to check for R_X86_64_32/R_X86_64_PLT32 and call __tls_get_addr explicitly. H.J.