Date: Tue, 7 Mar 2006 12:54:55 -0800 From: Marcel Moolenaar <marcel@xcllnt.net> To: pfgshield-freebsd@yahoo.com Cc: ports@freebsd.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: amd64 and -fPIC Message-ID: <20060307205455.GA11840@ns1.xcllnt.net> In-Reply-To: <20060307195849.70339.qmail@web32714.mail.mud.yahoo.com> References: <20060307192606.GA56153@xor.obsecurity.org> <20060307195849.70339.qmail@web32714.mail.mud.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Mar 07, 2006 at 08:58:49PM +0100, pfgshield-freebsd@yahoo.com wrote: > > An honest question: I would like to know what other modern architectures > require this, I heard (but I'm not sure) that it's a consequence of the > architecture running both 64 and 32 bit code so.. SPARC64 and ia64 need it too? Yes, ia64 has the same link constraints. I don't think sparc64 has the same problems, but that doesn't mean anything. A shared object has to be position independent and any object files that constitute the shared object have to be constructed in such a way. For C/C++ and GCC this means that -fPIC is required. Some platforms (i.e. i386) don't generate different code for -fPIC, so the omission of -fPIC when it is necessary doesn't result in problems. This is just a quirk of the platform, not the norm. Also, linking an archive library into a shared object is perfectly valid, provided of course that all object files in the archive library are compiled for inclusion in a shared object. This of course means that they must be position independent and thus compiled with -fPIC (or equivalent). As such, you must determine up front for what purpose you create an archive library (linking into an executable or linking into a shared object) or create 2 variants: one non-PIC and one PIC. A generic port that only builds archive libraries better be PIC to cover all bases. Performance cannot really be a concern when you're working with generic parts. If performance is a concern, customization is pretty much a given and the use of generic parts is almost always abandoned. The kicker: With the introduction of the __thread keyword to define thread local storage, i386 now also requires the correct use of -fPIC, because the code generated for thread local storage is different for PIC and non-PIC. As far as I know, *NO* architecture can link shared objects without proper use of -fPIC when thread local storage is to be considered. Beware!!!!! -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060307205455.GA11840>