The benefit of identifying symbols that don't need be preemptable is not only that more efficient references are available for global data and less call overhead, it is also protection against accidentally preempting a symbol that wasn't intended to be preempted in the first place. For example when building shared objects from several objects, it may be necessary for the linker to resolve references between the objects that make up the shared object, however the symbols need not be visible outside the shared object. In order for the linker to resolve symbol references between objects they must be global, but by making the symbols non-preemptable by, for example, setting the hidden ELF visibility attribute on the symbol will not only prevent the symbol can accidentally be preempted but also that any other component can link against the symbol. We would like to recommend that during development of new code the visibility attributes of global symbols are carefully considered and set explicitly on the symbol declaration in header files. This will enable better code generation as well as protection against accidental preemption.

User Models/Options
On Linux the default application model and the generic ELF ABI require the compiler to generate position independent code and, on Intel Itanium, to ensure that symbol preemption is allowed for global symbols. Relatively few applications take advantage of position independence or symbol preemption, and support for these features can cause significant run-time overhead. Therefore several performance opportunities are available to applications that don't require position independent code or the default symbol preemption model as described in the generic ELF ABI. We have worked on developing safe software convention models for Linux together with the Linux community and other industry leaders. The models rely on the ELF visibility attributes and the user providing input to tell the compiler that position independent code is not required for the main executable.

By default, global variables must be addressed indirectly, through the global offset table (GOT). This introduces an extra level of indirection to load a global scalar variable. In the example below there is a load of a 4 byte object named data:

add r3 = @ltoff(data),gp
ld8 r2 = [r3]
ld4 r8 = [r2]

The add instruction obtains the address of data's GOT entry using its offset from the component's global pointer (gp) address. The linker, which is responsible for allocating address slots in the GOT, fills in this offset in response to the ltoff (literal offset) relocation referencing the symbol data. The ld8 instruction fetches data's address from the GOT, and the ld4 instruction actually loads data's value.

The Intel Itanium ABI states that small data items such as data must be allocated in a special short data (.sdata) section that is directly addressable as an offset from gp. However, the compiler cannot take advantage of this, as that would violate symbol preemption rules. The object referred to by the symbol data may change at load time as a result of symbol preemption, and may end up at a location that cannot be directly addressed from the component's gp value. However, using the ELF visibility attributes we can tell the compiler and linker that a symbol cannot be preempted and therefore can be bound at link time, thus allowing the use of gp-relative addressing for the symbol. The default ELF visibility is default, meaning that the symbol can be preempted. If the ELF visibility of the global symbol is made protected or hidden, the compiler can assume that the symbol will be bound at link time. Item data can now be accessed as an offset from the component's gp:

add r2 = @gprel(data),gp
ld4 r8 = [r2]

If the object is compiled for the main executable component, and therefore will not be used in a dynamic shared library, it is possible to tell the compiler that the object being compiler does not require position independent code. The access generated for global symbols with ELF visibility other than default can now use an absolute address.

movl r2 = ltconst(data)
ld4 r8 = [r2]

Another benefit of using the non-default ELF visibility attributes is that calls to function symbols that are protected or hidden do not need to save and restore the gp value. Since the call will be bound at link time and cannot be preempted, the callee's gp value is guaranteed to be the same as the caller's.

» previous | next |  download | 175.75 KB | Intel Software Network resource center