If a shared object is built from code that is not position-independent, the text segment will usually require a large number of relocations to be performed at runtime. Although the runtime linker is equipped to handle this, the system overhead this creates can cause serious performance degradation. The compiler can generate position-independent code with -Kpic option. Ideally, any frequently accessed data items benefit from using the -Kpic model
-Kpic Vs -KPIC
----------------
Both -Kpic & -KPIC affect references to global offset table entries. The global offset table is an array of pointers, the size of whose entries are constant for 32–bit (4 bytes) and 64–bit (8–bytes).
The code sequence to make reference to an entry under -Kpic is something like:
ld [%l7 + j], %o0 ! load &j into %o0
Where %l7 is the precomputed value of the symbol _GLOBAL_OFFSET_TABLE_ of the object making the referenceThis code sequence provides a 13–bit displacement constant for the global offset table entry, and thus provides for 2048 unique entries (2^11) for 32–bit objects, and 1024 unique entries (2^10) for 64–bit objects. If an object is built that requires more than the available number of entries, the link-editor produces a fatal error:
$ CC -Kpic -G -o libhidden.so hidden.o extras.oTo overcome this error condition, some or all of the input relocatable objects have to be compiled with the -KPIC option
ld: fatal: too many symbols require `small' PIC references:
have 2050, maximum 2048 -- recompile some modules -K PIC.
Source:
Linker & Libraries Guide, Sun Microsystems Inc.,
0 comments:
Post a Comment