2.4 The symtypetab sections

These are two very simple sections with identical formats, used by consumers to map from ELF function and data symbols directly to their types. So they are usually populated only in CTF sections that are embedded in ELF objects.

Their format is very simple: an array of type IDs. Which symbol each type ID corresponds to depends on whether the optional index section associated with this symtypetab section has any content.

If the index section is nonempty, it is an array of uint32_t string table offsets, each giving the name of the symbol whose type is at the same offset in the corresponding non-index section: users can look up symbols in such a table by name. The index section and corresponding symtypetab section is usually ASCIIbetically sorted (indicated by the CTF_F_IDXSORTED flag in the header): if it’s sorted, it can be bsearched for a symbol name rather than having to use a slower linear search.

If the data object index section is empty, the entries in the data object and function info sections are associated 1:1 with ELF symbols of type STT_OBJECT (for data object) or STT_FUNC (for function info) with a nonzero value: the linker shuffles the symtypetab sections to correspond with the order of the symbols in the ELF file. Symbols with no name, undefined symbols and symbols named “_START_” and “_END_” are skipped and never appear in either section. Symbols that have no corresponding type are represented by type ID 0. The section may have fewer entries than the symbol table, in which case no later entries have associated types. This format is more compact than an indexed form if most entries have types (since there is no need to record any symbol names), but if the producer and consumer disagree even slightly about which symbols are omitted, the types of all further symbols will be wrong!

The compiler always emits indexed symtypetab tables, because there is no symbol table yet. The linker will always have to read them all in and always works through them from start to end, so there is no benefit having the compiler sort them either. The linker (actually, libctf’s linking machinery) will automatically sort unsorted indexed sections, and convert indexed sections that contain a lot of pads into the more compact, unindexed form.

If child dicts are in use, only symbols that use types actually mentioned in the child appear in the child’s symtypetab: symbols that use only types in the parent appear in the parent’s symtypetab instead. So the child’s symtypetab will almost always be very sparse, and thus will usually use the indexed form even in fully linked objects. (It is, of course, impossible for symbols to exist that use types from multiple child dicts at once, since it’s impossible to declare a function in C that uses types that are only visible in two different, disjoint translation units.)