kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)

Simon Hausmann simon.hausmann at nokia.com
Wed Aug 17 07:59:43 BST 2011

On Tuesday, August 16, 2011 09:05:53 PM ext Thiago Macieira wrote:
> On Tuesday, 16 de August de 2011 20:53:45 Alexander Neundorf wrote:
> > > However, it's still not perfectly correct: the issue is the difference
> > > between -fPIE and -fPIC. In a PIE, the compiler and linker *know* that
> > > this ELF module is the first open loaded,
> > 
> > Sorry, I don't understand that sentence. Is there something missing ?
> > Linker as in build time linker, or the loader ?
> Both.
> Rephrasing: when you use -fPIE to compile and -pie to link, the compiler, the 
> build-time linker and the runtime linker are under the assumption that your 
> code is the first ELF module to be loaded. That means the compiler and the 
> build-time linker may make use of certain constructions or relocations that 
> only work in the first ELF module and break elsewhere.
> One such example are copy relocations, at least in non-PIC non-PIE code. When 
> you write in your code:
> int main()
> {
>     errno = 0;
> }
> The variable errno is exported from libc.so.6. But instead of fetching the 
> address of that variable via GOT from libc.so.6, or even instead of leaving a 
> relocation for the address of that variable in your main function's code, what 
> the linker does is *copy* the variable. 
> Your main function will contain an absolute, non-relocatable address to a 
> variable in the application's .data segment. Then, the .data segment contains 
> an R_386_COPY (or R_ARM_COPY) relocation, that tells ld.so to get the value 
> from libc.so.6, write it there, and then make every other ELF module refer to 
> this symbol, not the one in libc.so.6.
> The same applies to another symbol familiar to us: QCoreApplication::self (a 
> private, static variable accessed in the inline QCoreApplication::instance 
> function).
> If PIE executables still have copy relocations, we cannot dlopen them.

PIE and copy relocations sound fundamentally in conflict to me, given that it relies
on the executable to be loaded at the correct address (to avoid a relocation in the
executable itself). Otoh being loadable at any address is what PIE is all about, no?

Can you think of any other example where PIE would differ from PIC?


P.S.: errno is a macro to (*errno_location()), pointing into TLS :)

More information about the kde-core-devel mailing list