(SPARC) Specify code address space.
It is highly recommended that you build shared objects by specifying -xcode=pic13 or -xcode=pic32. It is possible to build workable shared objects with -xarch=v9 -xcode=abs64 and with -xarch=v8 -xcode=abs32, but these will be inefficient. Shared objects built with -xarch=v9, -xcode=abs32, or -xarch=v9, -xcode=abs44 will not work.
v must be one of:
Table B–21 The -xcode Flags
Value |
Meaning |
abs32 |
This is the default on 32-bit architectures. Generates 32-bit absolute addresses. Code + data + bss size is limited to 2**32 bytes. |
abs44 |
This is the default on 64-bit architectures. Generates 44-bit absolute addresses. Code + data + bss size is limited to 2**44 bytes. Available only on 64–bit architectures. |
abs64 |
Generates 64-bit absolute addresses. Available only on 64-bit architectures. |
pic13 |
Generates position-independent code for use in shared libraries (small model). Equivalent to -Kpic. Permits references to at most 2**11 unique external symbols on 32-bit architectures, 2**10 on 64-bit architectures. |
pic32 |
Generates position-independent code for use in shared libraries (large model). Equivalent to -KPIC. Permits references to at most 2**30 unique external symbols on 32-bit architectures, 2**29 on 64-bit architectures. |
The default is -xcode=abs32 for 32–bit architectures. The default for 64–bit architectures is-xcode=abs44.
When building shared dynamic libraries, the default -xcode values of abs44 and abs32 will not work with 64–bit architectures. Specify -xcode=pic13 or -xcode=pic32 instead. There are two nominal performance costs with– xcode=pic13 and– xcode=pic32 on SPARC.
A routine compiled with either– xcode=pic13 or– xcode=pic32 executes a few extra instructions upon entry to set a register to point at a table (_GLOBAL_OFFSET_TABLE_) used for accessing a shared library’s global or static variables.
Each access to a global or static variable involves an extra indirect memory reference through _GLOBAL_OFFSET_TABLE_. If the compilation include -xcode=pic32, there are two additional instructions per global and static memory reference.
When considering the above costs, remember that the use of -xcode=pic13 and -xcode=pic32 can significantly reduce system memory requirements, due to the effect of library code sharing. Every page of code in a shared library compiled -xcode=pic13 or– xcode=pic32 can be shared by every process that uses the library. If a page of code in a shared library contains even a single non-pic (that is, absolute) memory reference, the page becomes nonsharable, and a copy of the page must be created each time a program using the library is executed.
The easiest way to tell whether or not a .o file has been compiled with -xcode=pic13 or– xcode=pic32 is with the nm command:
% nm file.o | grep _GLOBAL_OFFSET_TABLE_ U _GLOBAL_OFFSET_TABLE_ |
A .o file containing position-independent code contains an unresolved external reference to _GLOBAL_OFFSET_TABLE_, as indicated by the letter U.
To determine whether to use– xcode=pic13 or– xcode=pic32, check the size of the Global Offset Table (GOT) by using elfdump -c (see the elfdump(1) man page for more information) and to look for the section header, sh_name: .got. The sh_size value is the size of the GOT. If the GOT is less than 8,192 bytes, specify -xcode=pic13, otherwise specify -xcode=pic32.
In general, use the following guidelines to determine how you should use -xcode:
If you are building an executable you should not use– xcode=pic13 or -xcode=pic32.
If you are building an archive library only for linking into executables you should not use– xcode=pic13 or -xcode=pic32.
If you are building a shared library, start with– xcode=pic13 and once the GOT size exceeds 8,192 bytes, use -xcode=pic32.
If you are building an archive library for linking into shared libraries you should just use -xcode=pic32.