F.2 Having the Linker Relocate Stabs in ELF

This section describes some Sun hacks for Stabs in ELF; it does not apply to COFF or SOM. While GDB no longer supports this hack for Sun Stabs in ELF, this section is kept to document the issue.

To keep linking fast, you don’t want the linker to have to relocate very many stabs. Making sure this is done for N_SLINE, N_RBRAC, and N_LBRAC stabs is the most important thing (see the descriptions of those stabs for more information). But Sun’s stabs in ELF has taken this further, to make all addresses in the n_value field (functions and static variables) relative to the source file. For the N_SO symbol itself, Sun simply omits the address. To find the address of each section corresponding to a given source file, the compiler puts out symbols giving the address of each section for a given source file. Since these are ELF (not stab) symbols, the linker relocates them correctly without having to touch the stabs section. They are named Bbss.bss for the bss section, Ddata.data for the data section, and Drodata.rodata for the rodata section. For the text section, there is no such symbol (but there should be, see below). For an example of how these symbols work, See Stab Section Transformations. GCC does not provide these symbols; it instead relies on the stabs getting relocated. Thus addresses which would normally be relative to Bbss.bss, etc., are already relocated. The Sun linker provided with Solaris 2.2 and earlier relocates stabs using normal ELF relocation information, as it would do for any section. Sun has been threatening to kludge their linker to not do this (to speed up linking), even though the correct way to avoid having the linker do these relocations is to have the compiler no longer output relocatable values. Last I heard they had been talked out of the linker kludge. See Sun point patch 101052-01 and Sun bug 1142109. With the Sun compiler this affects ‘S’ symbol descriptor stabs (see Statics) and functions (see Procedures). In the latter case, to adopt the clean solution (making the value of the stab relative to the start of the compilation unit), it would be necessary to invent a Ttext.text symbol, analogous to the Bbss.bss, etc., symbols. I recommend this rather than using a zero value and getting the address from the ELF symbols.

Finding the correct Bbss.bss, etc., symbol is difficult, because the linker simply concatenates the .stab sections from each .o file without including any information about which part of a .stab section comes from which .o file. The way GDB use to do this is to look for an ELF STT_FILE symbol which has the same name as the last component of the file name from the N_SO symbol in the stabs (for example, if the file name is ../../gdb/main.c, it looks for an ELF STT_FILE symbol named main.c). This loses if different files have the same name (they could be in different directories, a library could have been copied from one system to another, etc.). It would be much cleaner to have the Bbss.bss symbols in the stabs themselves. Having the linker relocate them there is no more work than having the linker relocate ELF symbols, and it solves the problem of having to associate the ELF and stab symbols. However, no one has yet designed or implemented such a scheme.