> As we all know, shared objects want to be compiled with -fPIC.
No, shared objects are lifeless - users want to compile shared objects
with -fPIC :-)
> But shouldn't this be the linking loader's job? Why is there no fixup
> section for jumps?
Sure there is. At least on Linux, compiling shared libraries with
-fPIC is not an absolute requirement. If you don't, it will still work
- only it will require relocations on run-time. These result, due to
copy-on-write, that the shared pages are not shared anymore. Since
there is likely at least one relocation per page, you essentially have
to copy the entire library to swap on start-up.
> On the i386 platform relative jumps are limited to an 8 bit signed
> offset. In order to jump further than this the jumps must be threaded (I
> may be wrong about this, in truth it has been a while since I did any
> assembly on the Intels).
No. On the i386 platform, *all* jumps are PC-relative (except for the
indirect ones), so you can jump relatively to about any location you
want.
> 1) I'm right about the limitations of relative jumps on Intel
No, see above.
> 2) I'm totally wrong about the limitations of relative jumps on Intel,
> in which case this message qualifies as noise.
The problem is that the static linker can't know the final location of
a function in a shared library, so you still pay the overhead of going
through the PLT. In addition, there are no PC-relative read and write
operations - which is the real overhead of -fPIC on ia32
Regards,
Martin
