SPARC: -Kpic and -KPIC Options

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 code sequence to make reference to an entry under -K pic 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 reference.

This code sequence provides a 13–bit displacement constant for the global offset table entry, and thus provides for 2048 unique entries for 32–bit objects, and 1024 unique entries 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 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 or all 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 + j], %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, any 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. Recompiling all relocatable objects with the -K PIC option is typically easier.