STV_DEFAULT

The visibility of symbols with the STV_DEFAULT attribute is as specified by the symbol's binding type. That is, global and weak symbols are visible outside of their defining component, the executable file or shared object. Local symbols are hidden. Global and weak symbols can also be preempted, that is, they may by interposed by definitions of the same name in another component.

STV_PROTECTED

A symbol defined in the current component is protected if it is visible in other components but cannot be preempted. Any reference to such a symbol from within the defining component must be resolved to the definition in that component, even if there is a definition in another component that would interpose by the default rules. A symbol with STB_LOCAL binding will not have STV_PROTECTED visibility.

STV_HIDDEN

A symbol defined in the current component is hidden if its name is not visible to other components. Such a symbol is necessarily protected. This attribute is used to control the external interface of a component. An object named by such a symbol may still be referenced from another component if its address is passed outside.

A hidden symbol contained in a relocatable object is either removed or converted to STB_LOCAL binding by the link-editor when the relocatable object is included in an executable file or shared object.

STV_INTERNAL

This visibility attribute is currently reserved.

None of the visibility attributes affects the resolution of symbols within an executable or shared object during link-editing. Such resolution is controlled by the binding type. Once the link-editor has chosen its resolution, these attributes impose two requirements. Both requirements are based on the fact that references in the code being linked may have been optimized to take advantage of the attributes.

• First, all of the non-default visibility attributes, when applied to a symbol reference, imply that a definition to satisfy that reference must be provided within the current executable or shared object. If this type of symbol reference has no definition within the component being linked, then the reference must have STB_WEAK binding and is resolved to zero.

• Second, if any reference to or definition of a name is a symbol with a non-default visibility attribute, the visibility attribute must be propagated to the resolving symbol in the linked object. If different visibility attributes are specified for distinct references to or definitions of a symbol, the most constraining visibility attribute must be propagated to the resolving symbol in the linked object. The attributes, ordered from least to most constraining, are STV_PROTECTED, STV_HIDDEN and STV_INTERNAL.

If a symbol's value refers to a specific location within a section, its section index member, st_shndx, holds an index into the section header table. As the section moves during relocation, the symbol's value changes as well. References to the symbol continue to point to the same location in the program. Some special section index values give other semantics:

SHN_ABS

This symbol has an absolute value that does not change because of relocation.

SHN_COMMON

This symbol labels a common block that has not yet been allocated. The symbol's value gives alignment constraints, similar to a section's sh_addralign member. The link-editor allocates the storage for the symbol at an address that is a multiple of st_value. The symbol's size tells how many bytes are required.

SHN_UNDEF

This section table index means the symbol is undefined. When the link-editor combines this object file with another that defines the indicated symbol, this file's references to the symbol will be bound to the actual definition.

As mentioned above, the symbol table entry for index 0 (STN_UNDEF) is reserved. This entry holds the values listed in the following table.

Table 7-25 ELF Symbol Table Entry: Index 0

Symbol Values

Symbol table entries for different object file types have slightly different interpretations for the st_value member.

• In relocatable files, st_value holds alignment constraints for a symbol whose section index is SHN_COMMON.

• In relocatable files, st_value holds a section offset for a defined symbol. st_value is an offset from the beginning of the section that st_shndx identifies.

• In executable and shared object files, st_value holds a virtual address. To make these files' symbols more useful for the runtime linker, the section offset (file interpretation) gives way to a virtual address (memory interpretation) for which the section number is irrelevant.

Although the symbol table values have similar meanings for different object files, the data allow efficient access by the appropriate programs.

Register Symbols

The SPARC architecture supports register symbols, which are symbols that initialize a global register. A symbol table entry for a register symbol contains the entries listed in the following table.

Table 7-26 SPARC: ELF Symbol Table Entry: Register Symbol

The register values defined for SPARC are listed in the following table.

Table 7-27 SPARC: ELF Register Numbers

Absence of an entry for a particular global register means that the particular global register is not used at all by the object.

Syminfo Table Section

The syminfo section contains multiple entries of the type Elf32_Syminfo or Elf64_Syminfo. There is one entry in the .SUNW_syminfo section for every entry in the associated symbol table (sh_link).

If this section is present in an object, additional symbol information is to be found by taking the symbol index from the associated symbol table and using that to find the corresponding Elf32_Syminfo or Elf64_Syminfo entry in this section. The associated symbol table and the Syminfo table will always have the same number of entries.

Index 0 is used to store the current version of the Syminfo table, which is SYMINFO_CURRENT. Since symbol table entry 0 is always reserved for the UNDEF symbol table entry, this does not pose any conflicts.

An Symfino entry has the following format, defined in sys/link.h:

typedef struct {
        Elf32_Half      si_boundto;
        Elf32_Half      si_flags;
} Elf32_Syminfo;

typedef struct {
        Elf64_Half      si_boundto;
        Elf64_Half      si_flags;
} Elf64_Syminfo;

The elements of this structure are:

si_boundto

This index is to an entry in the .dynamic section, identified by the sh_info field, that augments the Syminfo flags. For example, a DT_NEEDED entry identifies a dynamic object associated with the Syminfo entry. The entries that follow are reserved values for si_boundto.

Table 7-28 ELF si_boundto Reserved Values

Name	Value	Meaning
SYMINFO_BT_SELF	0xffff	Symbol bound to self.
SYMINFO_BT_PARENT	0xfffe	Symbol bound to parent. The parent is the first object to cause this dynamic object to be loaded.
SYMINFO_BT_NONE	0xfffd	Symbol has no special symbol binding.

si_flags

This bit-field can have flags set, as shown in the following table.

Table 7-29 ELF Syminfo Flags

Name	Value	Meaning
SYMINFO_FLG_DIRECT	0x01	Symbol reference has direct association to object containing definition.
SYMINFO_FLG_COPY	0x04	Symbol definition is the result of a copy-relocation.
SYMINFO_FLG_LAZYLOAD	0x08	Symbol reference is to an object that should be lazily loaded.
SYMINFO_FLG_DIRECTBIND	0x10	Symbol reference should be bound directly to the definition.
SYMINFO_FLG_NOEXTDIRECT	0x20	Do not allow external reference to directly bind to this symbol definition.