On Wednesday, 17 de August de 2011 08:59:43 Simon Hausmann wrote: > 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: > > 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?
You're probably right. To make a relocation-free text, the access to variables must be made via the GOT, which in turn means it makes no difference whether the actual contents of the variable are in the application or in the library -- at least on 32-bit systems. > Can you think of any other example where PIE would differ from PIC? I can come up with ideas, given that the documentation says PIE is a specialisation of PIC for the first-loaded module. One idea is that variables are moved and the compiler uses a simpler, 32-bit PC-relative relocation to access them, as opposed to a 64-bit indirect as would be expected. Another, and far more likely, is that the compiler and linker expect that none of the symbols in the executable be overridden by any library. That is, it probably applies -Bsymbolic or something equivalent. If you have an application or library that expects to be able to override non-weak symbols by interposition, this could cause issues. Fortunately, this is very rare and frowned upon. -- 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
signature.asc
Description: This is a digitally signed message part.