For SPARC binaries, a subtle difference between the –K pic option and an alternative –K PIC option affects references to global offset table entries. See Global Offset Table (Processor-Specific).
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 following code sequence makes reference to an entry under –K pic.
ld [%l7 + j], %o0 ! load &j into %o0
This code sequence provides a 13–bit displacement constant for the global offset table entry. This displacement therefore provides for 2048 unique entries for 32–bit objects, and 1024 unique entries for 64–bit objects. If the creation of an object requires more than the available number of entries, the link-editor produces a fatal error.
$ cc -K pic -G -o lobfoo.so.1 a.o b.o .... z.o ld: fatal: too many symbols require 'small' PIC references: \ have 2050, maximum 2048 -- recompile some modules -K PIC.
To overcome this error condition, compile some of the input relocatable objects with the –K PIC option. This option provides a 32–bit constant for the global offset table entry.
sethi %hi(j), %g1 or %g1, %lo(j), %g1 ! get 32–bit constant GOT offset ld [%l7 + %g1], %o0 ! load &j into %o0
You can investigate the global offset table requirements of an object using elfdump(1) with the –G option. You can also examine the processing of these entries during a link-edit using the link-editors debugging tokens –D got,detail.
Ideally, frequently accessed data items benefit from using the –K pic model. You can reference a single entry using both models. However, determining which relocatable objects should be compiled with either option can be time consuming, and the performance improvement realized small. A recompilation of all relocatable objects with the –K PIC option is typically easier.