Why are symbols with local binding present in the symbol table of my ELF files?

Question

I found out that there are symbols with binding=LOCAL and visibility=HIDDEN in the symbol table (.symtab) of ELF executables/libraries. What are they needed for? They are not involved in the relocation process nor can be invoked externally. Are they included in the symbol table for exception handling?

Answer 1

Symbol Binding and Symbol Visibility

What are they needed for?

There must be a way for the link editor (ld) to determine the scope of a symbol during link-time. In other words, symbol binding allows the link editor to differentiate between symbols visible only within a particular file being linked (local scope) vs. symbols that can be referenced from within functions located in other files (global scope).

Symbol visibility attributes (default, protected, hidden or internal) have special meaning for the runtime- (dynamic) linker (ld-linux.so.*), telling it which symbols in the symbol table are used by the executable internally vs. which symbols may be used by other executables dynamically linked to it at program runtime.

From Why symbol visibility is good:

ELF has two related concepts for managing symbols in your programs. The first concept is the symbol binding. Global binding means the symbol is visible outside the file being built; local binding is the opposite and keeps the symbol local only (static) and weak is like global, but suggests that the symbol can be overridden.

This is all well and good, but starts breaking down when you want to load many different modules and keep strict API's (such as, say, dynamic libraries!).

Binding attributes are useful for the linker putting together object files; but aren't a complete solution.

To combat this, ELF provides for visibility attributes. Symbols can be default, protected, hidden or internal. Using these attributes, we can flag extra information for the dynamic loader so it can know which symbols are for public consumption, and which are for internal use only.

The most logical way to use this is to make all symbols by default hidden with -fvisibility=hidden and then "punch holes in the wall" for those symbols you want visible.

Symbols and Relocation

They are not involved in the relocation process

This is false.

From the System V ABI Edition 4.1 (generic), Chapter 4: Object Files, Relocation:

Relocation is the process of connecting symbolic references with symbolic definitions. For example, when a program calls a function, the associated call instruction must transfer control to the proper destination address at execution.

From the Oracle Linker and Libraries Guide, Part I: Using the Link-Editor and Runtime Linker, Section 2: Link Editor Symbol Processing:

During input file processing, all local symbols from the input relocatable objects are passed through to the output file image. All global symbols from the input relocatable objects, together with globals symbols from shared object dependencies, are accumulated internally within the link-editor.

Symbols and Program Runtime

nor can they be invoked externally

Symbols are never invoked during program runtime. During runtime the instruction pointer in the CPU jumps to the memory addresses in virtual memory of instructions located at offsets calculated by the link-editor (relocation). If symbols were relevant during runtime the symbol table could not be removed (stripped) from executable binaries.