Expand description
Which names this file may not work the address of out for itself.
Design: spec/11-asm-objects-debug.md section 11.3.
Everything this compiler emits is position independent, so the address of a name is the distance from the instruction asking to the name, and that distance is a number the assembler leaves a hole for and the linker fills in. The linker can only fill it in when it is putting both ends in the same program. A name this file only declares may turn out to be in a shared library, and then there is no such distance and the link fails rather than guessing one.
The way round it is a table: the linker gives the name one slot in the global offset table, fills the slot with whatever address the name ends up at, and the code loads the address out of the slot instead of working it out. The slot is in this program, so the distance to the slot is a number the linker has. It costs a load, and the linker takes the load back out again when the name turns out to have been in this program all along.
Which names need it is a fact about the whole module and the code generator sees one function at a time, which is why this is worked out first and handed in rather than asked at the point of use.
It is also a fact about which link is coming, which is rucc_ir::Pic and is why this is built
from more than the module. Under -fPIC the link may be one that produces a shared library, and
then a name this file exports is one the dynamic linker may find a different definition of, so
reaching it from the instruction pointer would reach the wrong one. The static linker will not
let that happen quietly: R_X86_64_PC32 against a name it can see is replaceable is refused
when it is making a shared object, which is how tamnd/rucc#756 was found.
Structsยง
- Elsewhere
- The names whose address only the linker knows.