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

[Thiago Macieira]

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.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20110816/eef724ca/attachment.sig>