From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 31 03:15:35 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id DB2DD16A409 for ; Sat, 31 Mar 2007 03:15:34 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from mxout2.cac.washington.edu (mxout2.cac.washington.edu [140.142.33.4]) by mx1.freebsd.org (Postfix) with ESMTP id 3172013C48C for ; Sat, 31 Mar 2007 03:15:34 +0000 (UTC) (envelope-from youshi10@u.washington.edu) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout2.cac.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2V3FXwi028186 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 30 Mar 2007 20:15:33 -0700 X-Auth-Received: from [192.168.10.7] (c-67-187-172-183.hsd1.ca.comcast.net [67.187.172.183]) (authenticated authid=youshi10) by smtp.washington.edu (8.13.7+UW06.06/8.13.7+UW07.03) with ESMTP id l2V3FWGo032513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 30 Mar 2007 20:15:33 -0700 Message-ID: <460DE02F.5020202@u.washington.edu> Date: Fri, 30 Mar 2007 20:14:39 -0800 From: Garrett Cooper User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org References: <200703310426.23953.pieter@degoeje.nl> In-Reply-To: <200703310426.23953.pieter@degoeje.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-PMX-Version: 5.3.0.289146, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.3.30.200638 X-Uwash-Spam: Gauge=IIIIIII, Probability=7%, Report='__CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0, __USER_AGENT 0' Subject: Re: Thread local storage not working with -fPIC and shared objects X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Mar 2007 03:15:35 -0000 Pieter de Goeje wrote: > Hello List, > > I have these files: > --- loader.cpp --- > #include > #include "tls.h" > > int main() { > tls = 0; > printf("%d\n", tls); > } > > --- tls.cpp --- > #include "tls.h" > int __thread tls; > > --- tls.h --- > extern __thread int tls; > > When I compile them like this: > c++ -fPIC -o tls.so tls.cpp -shared > c++ -fPIC -o loader loader.cpp tls.so > > And run the resulting program, I get: > pyotr@nox:~/projects/misc/tls> ./loader > /libexec/ld-elf.so.1: ./loader: Unsupported relocation type 37 in non-PLT > relocations > > When I omit -fPIC, it runs fine. But I need fPIC for the shared object on > amd64 arch. I've tried it on Linux/i386 (gcc 4.1) and it ran fine (with > fPIC). > > Much to my surprise however, a particularly large application I'm working on > did compile & run on FreeBSD/amd64 using -fpic (lowercase) and gcc 4.3. > Trying -fpic on FreeBSD/i386 resulted in failure. > > FYI, I need tls to work because I'm using OpenMP's tls (#pragma omp > threadprivate()) support in gcc 4.3. > > The workaround I found on FreeBSD/amd64 was linking the main executable > with -fno-PIC, or building everything with -fpic. (both workarounds didn't > work on FreeBSD/i386) > > I would be grateful if someone could shed some light on this. > > Regards, > Pieter de Goeje Pieter, Did you know that -fPIC and -fpic aren't the same? From : |-fpic| Generate position-independent code (PIC) suitable for use in a shared library, if supported for the target machine. Such code accesses all constant addresses through a global offset table (GOT). The dynamic loader resolves the GOT entries when the program starts (the dynamic loader is not part of GCC; it is part of the operating system). If the GOT size for the linked executable exceeds a machine-specific maximum size, you get an error message from the linker indicating that -fpic does not work; in that case, recompile with -fPIC instead. (These maximums are 8k on the SPARC and 32k on the m68k and RS/6000. The 386 has no such limit.) Position-independent code requires special support, and therefore works only on certain machines. For the 386, GCC supports PIC for System V but not for the Sun 386i. Code generated for the IBM RS/6000 is always position-independent. |-fPIC| If supported for the target machine, emit position-independent code, suitable for dynamic linking and avoiding any limit on the size of the global offset table. This option makes a difference on the m68k, PowerPC and SPARC. Position-independent code requires special support, and therefore works only on certain machines. Cheers, -Garrett