Loving ld with --as-needed

[John Richard Moser]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Scott James Remnant wrote:
> On Wed, 2005-03-02 at 23:47 -0500, John Richard Moser wrote:
[...]

>>Relocations?  Aren't those for ill-designed code that has some code in
>>it that can't execute at the position it's loaded, so is moved
>>elsewhere?  Proper libraries should be pure PIC.
>>
> 
> You have to perform relocation whenever the load address of an
> application or shared library doesn't match that at build time.  ie. you
> need to perform relocations on every PIC library.
> 

Um.  If it's "position independent," then it doesn't need to be at a
specific load address.

You can load a library at any point in memory and it should run fine.
If part of the code needs to be at a certain location, you'll have to
pick that code up and put it elsewhere, hence, relocate.

PaX allows relocations to be banned, meaning programs die when they
perform a relocation.  Any PIE programs with all pure PIC libraries run;
any libraries that have some non-PIC in them will die.  Of course this
adds an extra-tight restriction to the environment, which is fine if
everyone works with it.  I'm not sure if X works with this yet; but you
can work at the console with it.

Ask Brad Spengler, the PaX team, or anyone from the Hardened Gentoo team
what's up with this, they may have a different definition of relocation
than you do; though I'm fairly certain they're thinking of what the
toolchain calls a relocation, as this is where the topic of relocations
came from (toolchain modification is heavy on the hardened front).

Generally, inline assembly code in a library or what would become a PIE
will cause a relocation.

> If you're interested, read:
> 	http://people.redhat.com/drepper/dsohowto.pdf
> 
> Scott
> 

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

    Creative brains are a valuable, limited resource. They shouldn't be
    wasted on re-inventing the wheel when there are so many fascinating
    new problems waiting out there.
                                                 -- Eric Steven Raymond
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCQ3eBhDd4aOud5P8RAoknAJ9FfzwCs5jG6dhgWtUHDkN4pXB8RQCfaHaw
wWMRlIc+NLS8nlBIEUWnJjk=
=MqnT
-----END PGP SIGNATURE-----