B.2.80 -xcode[=v] (Sun Studio 12: C User's Guide)

Sun Studio 12: C User's Guide

B.2.80 `-xcode`[`=v`]

(SPARC) Specify code address space.

Note –

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 211 unique external symbols on 32-bit architectures, 210 on 64-bit architectures.
`pic32`	Generates position-independent code for use in shared libraries (large model). Equivalent to `-KPIC`. Permits references to at most 230 unique external symbols on 32-bit architectures, 229 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.