libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PIE support


From: Ralf Wildenhues
Subject: Re: PIE support
Date: Wed, 30 Nov 2005 20:23:49 +0100
User-agent: Mutt/1.5.9i

Hi Paul,

* Paul Jakma wrote on Wed, Nov 30, 2005 at 08:13:14PM CET:
> On Wed, 30 Nov 2005, Mike Frysinger wrote:
> 
> >PIE and PIC arent the same thing

> The distinction between the two is mostly important at link-time. Ie 
> a collection of PIC and/or PIE objects can be linked together into a 
> PIE executable.
> 
> What I'm curious about is what the difference is in generated /code/ 
> for an object /before/ linking done between PIC and PIE. Is there an 
> efficiency/performance gain in generating PIE code over PIC?

Yes.

> If so, is the gain over PIC sufficiently large to be relevant to
> Ralf's patch

My patch _enables you_ to take advantage of exactly this efficiency
gain.

> (which, if I understand correctly, will compile all code as PIC if
> -fpie is supplied).

Wrong.  It will create a PIC .libs/foo.o and a PIE foo.o.

> If efficiency of PIE targeted code is sufficiently greater than PIC, 
> then, AIUI, that would require libtool to distinguish between 
> additional modes of compiling objects intended for shared usage (PIC) 
> and not (PIE).
> 
> Is my understanding anyway.
> 
> Alternatively, projects would need to tailor their build systems to 
> make the distinction between possibly-intended-to-link-into-shared 
> and other ojbects.

You haven't understood the patch.  Please try it.  It does _exactly_ the
right thing, if you supply CFLAGS=-fpie:
- all non-libtool-created objects will be PIE
- all libtool-created objects will have one PIE and one PIC version.
  Only the latter will end up in shared libraries, only the former will
  end up in program binaries.

Enjoy.  :)

(Do you want me to post a backport?)

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]