On Apr 10, 2013, at 2:07 AM, Niels Möller wrote:
Perry Smith pedzsan@gmail.com writes:
It would be interesting to see what platforms need the non-pic mode. I've not heard of anything other than position independent code for a fairly long time now.
I think it matters in two ways.
- On processors that lack general pc-relative addressing, e.g., x86_32,
pic code causes additonal overhead when, e.g., addressing constant data tables. I think there are some issues on x86_64 darwin as well, but I guess that's just problems with Apple's tools, nothing fundamental.
- Constant data structures which contain absolute pointers, like
nettle's
const struct nettle_cipher nettle_aes128;If you do position independent code, the pointers have to be relocated at load time, so the structure has to be allocated in the data segment (despite "const"). If we allow position dependent code, the structure can be put into the rodata segment where one might expect it, with relocation done only at link time.
The default output of IBM's xlc compiler as well as GNU's gcc compiler is to produce position independent code for AIX. I believe that is true for any Power PC platform. And I thought that that was true for almost any modern chip (Intel, etc).
Ok, so on those platforms we shouldn't pass any special flags for compilation. I guess we still need some xlc-specific options if we use xlc for *linking* the shared library?
Ok. I looked at the gcc manual about -fPIC. I'm surprised. I thought hardware had evolved more.
In any case, it did confirm: "Code generated for the IBM RS/6000 is always position-independent." (This is true for both compilers.) Also, just to be clear, I'm using GCC.
The suggestion I had was to have SUFFIX (like you have) and PIC_SUFFIX. For the RS/6000 and Power PC, PIC_SUFFIX could be .o so it would not recompile all the code a second time.
The other idea I had is to have a .pic directory and put the PIC objects in that directory with a normal .o suffix.
Perry