[The World of Linkers—Theory 07] Leave the Last Address to Runtime

The filenames in the commands below are placeholders for the inputs and outputs of this observation; choose any working directory.

Static PIE needs to discover where its own image landed. Shared libraries add another question: which image will supply a name this time? Even a function defined inside a library may be replaced by a definition elsewhere.

The kernel maps the interpreter named by PT_INTERP and starts it. That dynamic loader then locates dependencies, chooses definitions, and completes addresses. musl¹ combines libc with its loader; glibc² normally separates them. Their common unfinished task is runtime binding, not necessarily the same sequence of file mappings.

This chapter uses native x86-64 Linux throughout: Clang/LLD 21.1.8, GCC³ 15.2, GNU⁴ binutils⁵ 2.46, musl 1.2.5 through musl-gcc⁶, and glibc 2.43 through system GCC. glibc-specific features such as lazy binding and LD_DEBUG are tested with glibc programs. The examples below state the commands and observations directly.

Why not patch every instruction at startup?

We will follow this library:

1
// vec.c
2
int counter;
3

4
__attribute__((noinline)) int helper(int x) { return x * 2; }
5

6
int bump(int x) {
7
    counter += helper(x);
8
    return counter;
9
}

noinline keeps the internal call visible. Compile ordinary non-PIC code and try to make a shared object:

1
$ clang -fno-pic -O1 -c vec.c -o vec_nopic.o
2
$ llvm-objdump -dr --no-show-raw-insn vec_nopic.o
3
0000000000000010 <bump>:
4
      10:      	pushq	%rax
5
      11:      	callq	0x16 <bump+0x6>
6
		0000000000000012:  R_X86_64_PLT32	helper-0x4
7
      16:      	addl	(%rip), %eax            # 0x1c <bump+0xc>
8
		0000000000000018:  R_X86_64_PC32	counter-0x4
9
      1c:      	movl	%eax, (%rip)            # 0x22 <bump+0x12>
10
		000000000000001e:  R_X86_64_PC32	counter-0x4
11
      22:      	popq	%rcx
12
      23:      	retq
13
$ ld.lld -shared vec_nopic.o -o x.so
14
ld.lld: error: relocation R_X86_64_PC32 cannot be used against symbol 'counter'; recompile with -fPIC
15
>>> defined in vec_nopic.o
16
>>> referenced by vec.c
17
>>>               vec_nopic.o:(bump)

PC32 needs a link-time distance to counter, yet runtime interposition may place the chosen definition in another module. A wider absolute address makes the problem representable, but moves the patch into executable code:

1
$ cat abs.c
2
int counter;
3
int *get(void){ return &counter; }
4
$ clang -fno-pic -mcmodel=large -O1 -c abs.c -o abs.o
5
$ llvm-objdump -dr --no-show-raw-insn abs.o
6
Disassembly of section .ltext:
7

8
0000000000000000 <get>:
9
       0:      	movabsq	$0x0, %rax
10
		0000000000000002:  R_X86_64_64	counter
11
       a:      	retq
12
$ ld.lld -shared -z notext abs.o -o abs.so
13
$ readelf -d abs.so | grep -E 'TEXTREL|FLAGS'
14
 0x000000000000001e (FLAGS)              TEXTREL
15
 0x0000000000000016 (TEXTREL)            0x0
16
$ readelf -r abs.so
17
Relocation section '.rela.dyn' at offset 0x310 contains 1 entry:
18
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
19
000000001332  000200000001 R_X86_64_64       0000000000005440 counter + 0

-z notext permits the displayed text relocation. The loader must temporarily arrange write access, patch the address, and restore protection. With private file mappings, the write also creates process-private code pages. Different load addresses mean different patched contents, reducing physical sharing and adding startup work.

PIC⁷ instead keeps uncertain addresses in a compact writable structure while preserving immutable instructions. Relative references to a non-preemptible local target stay valid because source and target move together. Other references reach a nearby GOT⁸ slot, whose full-width address can be filled at runtime.

1
$ clang -fPIC -O1 -c vec.c -o vec.o
2
$ llvm-objdump -d -r --no-show-raw-insn vec.o
3
0000000000000000 <helper>:
4
       0:      	leal	(%rdi,%rdi), %eax
5
       3:      	retq
6
       4:      	nopw	%cs:(%rax,%rax)
7

8
0000000000000010 <bump>:
9
      10:      	pushq	%rax
10
      11:      	callq	0x16 <bump+0x6>
11
		0000000000000012:  R_X86_64_PLT32	helper-0x4
12
      16:      	movq	(%rip), %rcx            # 0x1d <bump+0xd>
13
		0000000000000019:  R_X86_64_REX_GOTPCRELX	counter-0x4
14
      1d:      	addl	(%rcx), %eax
15
      1f:      	movl	%eax, (%rcx)
16
      21:      	popq	%rcx
17
      22:      	retq

The new sequence loads counter's address, then reads/writes the object through it. Why use indirection when the source itself defines counter and helper? ELF⁹ default-visible definitions in shared objects are normally eligible for interposition. Compilation must respect that contract unless stronger visibility or binding information says otherwise.

PIE¹⁰ makes the main executable movable too, but its own definitions occupy the leading role in normal global lookup. Its compiler can often use direct relative references where a shared library needs indirection.

The static linker writes a runtime instruction sheet

An input relocation can request a GOT slot without containing one. The linker creates the slot and describes its remaining work:

1
$ ld.lld -shared -soname libvec.so.1 vec.o -o libvec.so.1

1
$ readelf -d libvec.so.1
2
Dynamic section at offset 0x3b0 contains 15 entries:
3
  Tag        Type                         Name/Value
4
 0x000000000000000e (SONAME)             Library soname: [libvec.so.1]
5
 0x0000000000000007 (RELA)               0x2d8
6
 0x0000000000000008 (RELASZ)             24 (bytes)
7
 0x0000000000000009 (RELAENT)            24 (bytes)
8
 0x0000000000000017 (JMPREL)             0x2f0
9
 0x0000000000000002 (PLTRELSZ)           24 (bytes)
10
 0x0000000000000003 (PLTGOT)             0x34a8
11
 0x0000000000000014 (PLTREL)             RELA
12
 0x0000000000000006 (SYMTAB)             0x200
13
 0x000000000000000b (SYMENT)             24 (bytes)
14
 0x0000000000000005 (STRTAB)             0x2b0
15
 0x000000000000000a (STRSZ)              33 (bytes)
16
 0x000000006ffffef5 (GNU_HASH)           0x260
17
 0x0000000000000004 (HASH)               0x288
18
 0x0000000000000000 (NULL)               0x0

PT_DYNAMIC locates a tag/value array. The loader does not need section headers to find the runtime structures.

A tag determines how to interpret its value

An Elf64_Dyn occupies 16 bytes: an eight-byte signed tag, d_tag, followed by an eight-byte union, d_un. The latter can represent an integer, d_val, or an address, d_ptr. The tag selects the interpretation; the numeric magnitude does not. DT_NULL terminates the array (gABI Dynamic Section).

Tag in this example	Value category	Interpretation with load bias B
`DT_RELA = 0x2d8`	Linked virtual address	Relocation-table start is `B + 0x2d8`
`DT_RELASZ = 24`	Byte count	Length stays 24; do not add B
`DT_RELAENT = 24`	Record width	`24 / 24 = 1` record
`DT_STRTAB = 0x2b0`	Linked virtual address	String-table start is `B + 0x2b0`
Raw value of `DT_SONAME`	String-table-relative offset	Add it to the string-table start and read a zero-terminated name
`DT_PLTREL = DT_RELA`	Format tag	PLT relocations use RELA; this is not a pointer

readelf has already interpreted the SONAME offset as [libvec.so.1] and the PLTREL value as RELA. On disk, each still occupies the same eight-byte value field. Address entries use this module’s load bias; lengths, record widths, string offsets, and format tags retain their own meanings and origins.

Dynamic tags	Runtime purpose
`SYMTAB`, `STRTAB`	Dynamic symbols and names
`GNU_HASH`, `HASH`	Name-lookup acceleration
`RELA`, `RELASZ`	General dynamic relocations
`JMPREL`, `PLTRELSZ`	PLT-related relocation table
`PLTGOT`	GOT/PLT control area
`SONAME`, `NEEDED`	Library identity advertised to dependents, and dependencies
`INIT`, `INIT_ARRAY`, `FINI`, `FINI_ARRAY`	Initialization/finalization hooks

Unlike .symtab, .dynsym must remain mapped because runtime lookup uses it. GNU hash adds a Bloom filter to cheaply reject many absent names. DT_DEBUG starts empty in the file and can receive a runtime debugger rendezvous structure.

Link a user of the library:

1
// main.c
2
extern int counter;
3
int bump(int);
4

5
int main(void) {
6
    bump(1);
7
    return counter;
8
}

1
$ ln -sf libvec.so.1 libvec.so
2
$ clang -fPIE -O1 -c main.c -o main_pie.o
3
$ musl-gcc -pie main_pie.o -L. -lvec -Wl,-rpath,'$ORIGIN' -o main_pie
4
$ readelf -d main_pie
5
Dynamic section at offset 0x2dd8 contains 26 entries:
6
  Tag        Type                         Name/Value
7
 0x0000000000000001 (NEEDED)             Shared library: [libvec.so.1]
8
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]
9
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
10
 0x000000000000000c (INIT)               0x1000
11
 0x000000000000000d (FINI)               0x1176
12
 0x0000000000000019 (INIT_ARRAY)         0x3dc8
13
 0x000000000000001b (INIT_ARRAYSZ)       8 (bytes)
14
 0x000000000000001a (FINI_ARRAY)         0x3dd0
15
 0x000000000000001c (FINI_ARRAYSZ)       8 (bytes)
16
 0x000000006ffffef5 (GNU_HASH)           0x258
17
 0x0000000000000005 (STRTAB)             0x360
18
 0x0000000000000006 (SYMTAB)             0x288
19
 0x000000000000000a (STRSZ)              141 (bytes)
20
 0x000000000000000b (SYMENT)             24 (bytes)
21
 0x0000000000000015 (DEBUG)              0x0
22
 0x0000000000000003 (PLTGOT)             0x3fb8
23
 0x0000000000000002 (PLTRELSZ)           48 (bytes)
24
 0x0000000000000014 (PLTREL)             RELA
25
 0x0000000000000017 (JMPREL)             0x498
26
 0x0000000000000007 (RELA)               0x3f0
27
 0x0000000000000008 (RELASZ)             168 (bytes)
28
 0x0000000000000009 (RELAENT)            24 (bytes)
29
 0x000000000000001e (FLAGS)              BIND_NOW
30
 0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE
31
 0x000000006ffffff9 (RELACOUNT)          3
32
 0x0000000000000000 (NULL)               0x0

The command finds libvec.so; the library advertises libvec.so.1, so that SONAME becomes the executable's dependency. Incompatible library generations can use different SONAMEs and coexist.

$ORIGIN expands at runtime to the containing object's directory. Quote it when passing it through the shell:

1
$ musl-gcc -pie main_pie.o -L. -lvec -Wl,--enable-new-dtags,-rpath,'$ORIGIN' -Wl,-z,now -o main_pie2
2
$ readelf -d main_pie2 | grep -E 'RUNPATH|FLAGS'
3
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
4
 0x000000000000001e (FLAGS)              BIND_NOW
5
 0x000000006ffffffb (FLAGS_1)            Flags: NOW PIE

1
$ ld.lld -shared -rpath '$ORIGIN' vec.o -o r_lld.so
2
$ readelf -d r_lld.so | grep PATH
3
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
4
$ ld -shared -rpath '$ORIGIN' vec.o -o r_bfd.so
5
$ readelf -d r_bfd.so | grep PATH
6
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]

Both tested linkers default to RUNPATH, but explicit --enable-new-dtags or --disable-new-dtags makes the choice reviewable. RPATH and RUNPATH differ in precedence and transitive behavior, discussed below.

A dependency entry has a startup cost. Compare an unused library with and without --as-needed:

1
$ musl-gcc -pie main_pie.o -L. -lvec -lother -o m1
2
$ readelf -d m1 | grep NEEDED
3
 0x0000000000000001 (NEEDED)             Shared library: [libvec.so.1]
4
 0x0000000000000001 (NEEDED)             Shared library: [libother.so]
5
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]
6
$ musl-gcc -pie main_pie.o -L. -Wl,--as-needed -lvec -lother -o m2
7
$ readelf -d m2 | grep NEEDED
8
 0x0000000000000001 (NEEDED)             Shared library: [libvec.so.1]
9
 0x0000000000000001 (NEEDED)             Shared library: [libc.so]

The option is position-sensitive and affects subsequent library inputs under the linker's dependency rules. It can omit a library that contributes no required resolution, instead of retaining every named shared input.

Unresolved references have a different policy in a shared object:

1
$ cat lib2.c
2
int missing(int);
3
int use(int x) { return missing(x) + 1; }
4
$ clang -fPIC -O1 -c lib2.c -o lib2.o
5
$ ld.lld -shared lib2.o -o lib2.so
6
$ readelf --dyn-syms lib2.so | grep missing
7
     1: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND missing
8
$ ld.lld -shared -z defs lib2.o -o lib2.so
9
ld.lld: error: undefined symbol: missing
10
>>> referenced by lib2.c
11
>>>               lib2.o:(use)
12
$ ld -shared --no-undefined lib2.o -o lib2.so
13
ld: lib2.o: in function `use':
14
lib2.c:(.text+0x2): undefined reference to `missing'

A plugin may intentionally obtain a name from its eventual host, so the default shared link permits unresolved symbols. -z defs/--no-undefined asks for link-time resolution against supplied inputs and catches many accidental omissions earlier.

The executable also names the interpreter and dynamic-table location:

1
$ readelf -lW main_pie
2
Elf file type is DYN (Position-Independent Executable file)
3
Entry point 0x1050
4
There are 9 program headers, starting at offset 64
5

6
Program Headers:
7
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
8
  PHDR           0x000040 0x0000000000000040 0x0000000000000040 0x0001f8 0x0001f8 R   0x8
9
  INTERP         0x000238 0x0000000000000238 0x0000000000000238 0x000019 0x000019 R   0x1
10
      [Requesting program interpreter: /lib/ld-musl-x86_64.so.1]
11
  LOAD           0x000000 0x0000000000000000 0x0000000000000000 0x0004c8 0x0004c8 R   0x1000
12
  LOAD           0x001000 0x0000000000001000 0x0000000000001000 0x000179 0x000179 R E 0x1000
13
  LOAD           0x002000 0x0000000000002000 0x0000000000002000 0x000074 0x000074 R   0x1000
14
  LOAD           0x002dc8 0x0000000000003dc8 0x0000000000003dc8 0x000240 0x000248 RW  0x1000
15
  DYNAMIC        0x002dd8 0x0000000000003dd8 0x0000000000003dd8 0x0001e0 0x0001e0 RW  0x8
16
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0x10
17
  GNU_RELRO      0x002dc8 0x0000000000003dc8 0x0000000000003dc8 0x000238 0x000238 R   0x1

Those program headers, dynamic tags, and dynamic symbols are the contract handed to the runtime loader.

Six relocation jobs, not one

Input relocations are normally consumed by the static link. Remaining work is expressed as dynamic relocations; their offsets identify image virtual addresses rather than offsets within separate input sections. TLS¹¹ relocations are deferred to Theory 09.

Compute the destination separately from the value

The name r_offset does not imply one coordinate system for every ELF type. In an ET_REL object it is relative to the target input section; in an executable or shared object it is the relocated field’s linked virtual address (gABI Relocation). A shared object loaded with bias B therefore writes at B + r_offset. This B belongs to the module containing the field, which need not supply the symbol definition.

For the RELATIVE record shown below, r_offset=0x3338 and A=0x3348. With hypothetical B=0x70000000, the loader writes the eight-byte pointer 0x70003348 at 0x70003338. Its little-endian encoding is 48 33 00 70 00 00 00 00. The destination answers “where”; the computed pointer answers “what”. RELATIVE uses its own module’s B for both and performs no name lookup.

For GLOB_DAT, the destination is still the referring module’s B + r_offset, but the value is the selected symbol’s runtime address S. A definition in another shared object uses that object’s bias. Interposition can select a different definition altogether, so this module’s same-named symbol value cannot substitute for lookup.

1
$ readelf -r libvec.so.1
2
Relocation section '.rela.dyn' at offset 0x2d8 contains 1 entry:
3
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
4
0000000024a0  000300000006 R_X86_64_GLOB_DAT 00000000000034c8 counter + 0
5

6
Relocation section '.rela.plt' at offset 0x2f0 contains 1 entry:
7
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
8
0000000034c0  000100000007 R_X86_64_JUMP_SLO 0000000000001360 helper + 0

GLOB_DAT looks up counter and places its runtime address in a GOT slot. JUMP_SLOT similarly supplies a function target but can participate in lazy binding. RELATIVE avoids name lookup entirely:

1
$ cat rel.c
2
static int table[4];
3
int *cursor = &table[2];
4
$ clang -fPIC -O1 -c rel.c -o rel.o
5
$ llvm-objdump -r rel.o
6
RELOCATION RECORDS FOR [.data]:
7
OFFSET           TYPE                     VALUE
8
0000000000000000 R_X86_64_64              .bss+0x8
9
$ ld.lld -shared rel.o -o librel.so
10
$ readelf -r librel.so
11
Relocation section '.rela.dyn' at offset 0x270 contains 1 entry:
12
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
13
000000003338  000000000008 R_X86_64_RELATIVE                    3348

The local table cannot be preempted. The linker already knows that &table[2] lies at image offset 0x3348, so the loader writes B+0x3348 at B+0x3338. A RELACOUNT prefix can identify a batch of cheap relative relocations.

Packing repeated relative adjustments

RELR records only where to add the base; the original field holds the addend. A word with low bit zero gives an address and advances the cursor by one word. A word with low bit one is a bitmap for the next 63 ELF64 words, then advances past that window.

1
$ gcc -fPIE -O1 -c relr.c -o relr.o
2
$ gcc -pie relr.o -o relr_plain
3
$ gcc -pie -Wl,-z,pack-relative-relocs relr.o -o relr_packed
4
$ readelf -SW relr_plain | grep "rel.\.dyn"
5
$ readelf -SW relr_packed | grep "rel.\.dyn"
6
  [ 8] .rela.dyn         RELA            0000000000000510 000510 0030c0 18   A  4   0  8
7
  [ 8] .rela.dyn         RELA            0000000000000530 000530 000078 18   A  4   0  8
8
  [ 9] .relr.dyn         RELR            00000000000005a8 0005a8 000058 08   A  0   0  8
9

10
$ readelf -rW relr_packed | grep -A5 relr.dyn
11
Relocation section '.relr.dyn' at offset 0x5a8 contains 11 entries which relocate 515 locations:
12
Index: Entry            Address           Symbolic Address
13
0000:  0000000000003dc0 0000000000003dc0  __frame_dummy_init_array_entry
14
0001:  0000000000000003 0000000000003dc8  __do_global_dtors_aux_fini_array_entry
15
0002:  ffffffffffffe401 0000000000004008  __dso_handle
16
                        0000000000004020  ptrs

This example has 515 relative locations: 512 pointers plus startup-array entries and __dso_handle. The ordinary relocation table occupies 12480 bytes including five GLOB_DAT entries. Packing leaves 120 bytes of .rela.dyn and 88 bytes—eleven words—of .relr.dyn. The first address 0x3dc0 and bitmap 0x3 cover two adjacent locations; later bitmaps span the pointer array.

Both tested runtime libraries execute the packed version successfully. The glibc binary records a GLIBC_ABI_DT_RELR version requirement. Format support must exist on both the producer and consumer side; a smaller file alone proves neither compatibility nor correct loading.

Local pointers, public pointers, and resolvers

Which target a pointer denotes determines whether lookup can be skipped:

1
$ cat ptr.c
2
static int table[4];
3
static int quiet(int x) { return x; }
4
__attribute__((visibility("hidden"))) int hid(int x) { return x + 1; }
5
int loud(int x) { return x + 2; }
6

7
int *cursor = &table[2];
8
const char *msg = "hi";
9
int (*ops[3])(int) = { quiet, hid, loud };
10
$ clang -fPIC -O1 -c ptr.c -o ptr.o
11
$ ld.lld -shared ptr.o -o libptr.so
12
$ readelf -r libptr.so
13
Relocation section '.rela.dyn' at offset 0x2f0 contains 5 entries:
14
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
15
0000000034b0  000000000008 R_X86_64_RELATIVE                    34e8
16
0000000034b8  000000000008 R_X86_64_RELATIVE                    368
17
0000000034c0  000000000008 R_X86_64_RELATIVE                    13f0
18
0000000034c8  000000000008 R_X86_64_RELATIVE                    13d0
19
0000000034d0  000100000001 R_X86_64_64       00000000000013e0 loud + 0

Static objects/functions, hidden definitions, and string literals use RELATIVE here. A pointer to default-visible loud needs a symbol-bearing R_X86_64_64, applying S+A after runtime lookup. Large C++ tables can contain many such entries when their function targets remain preemptible.

IFUNC adds a computation to resolution:

1
$ cat ifn.c
2
extern int has_avx2;
3
static int add_sse(int a, int b) { return a + b; }
4
static int add_avx(int a, int b) { return b + a; }
5
static void *pick(void) { return has_avx2 ? (void *)add_avx : (void *)add_sse; }
6
__attribute__((visibility("hidden"))) int add(int, int) __attribute__((ifunc("pick")));
7
int call(int a, int b) { return add(a, b); }
8
$ clang -fPIC -O1 -c ifn.c -o ifn.o
9
$ ld.lld -shared ifn.o -o libifn.so
10
$ readelf -r libifn.so | grep IREL
11
000000003448  000000000025 R_X86_64_IRELATIV                    1350
12
$ readelf -s libifn.so | grep -E ' (pick|add)$'
13
     2: 0000000000001350    29 FUNC    LOCAL  DEFAULT    7 pick
14
     5: 0000000000001350    29 IFUNC   LOCAL  HIDDEN     7 add

For hidden add, IRELATIVE identifies a resolver at B+A, calls it, and stores its returned implementation address. A preemptible IFUNC may instead be reached through normal symbol lookup and JUMP_SLOT handling. The displayed resolver is a mechanism demonstration; a production CPU-dispatch resolver must obey the early-runtime restrictions of its implementation.

Copy relocations create storage in the executable

Non-PIC code may directly address an external variable even when its definition eventually comes from a shared library:

1
$ clang -fno-pic -O1 -c main.c -o main_nopic.o
2
$ llvm-objdump -dr --no-show-raw-insn main_nopic.o
3
0000000000000000 <main>:
4
       0:      	pushq	%rax
5
       1:      	movl	$0x1, %edi
6
       6:      	callq	0xb <main+0xb>
7
		0000000000000007:  R_X86_64_PLT32	bump-0x4
8
       b:      	movl	(%rip), %eax            # 0x11 <main+0x11>
9
		000000000000000d:  R_X86_64_PC32	counter-0x4
10
      11:      	popq	%rcx
11
      12:      	retq

The linker creates nearby executable-owned storage and asks the loader to copy the library's initial bytes into it:

1
$ musl-gcc -no-pie main_nopic.o -L. -lvec -Wl,-rpath,'$ORIGIN' -o main_nopie_musl
2
$ readelf -rW main_nopie_musl
3
Relocation section '.rela.dyn' at offset 0x3f8 contains 4 entries:
4
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
5
0000000000403fd0  0000000500000006 R_X86_64_GLOB_DAT      0000000000000000 __cxa_finalize + 0
6
0000000000403fd8  0000000100000006 R_X86_64_GLOB_DAT      0000000000000000 _ITM_registerTMCloneTable + 0
7
0000000000403fe0  0000000200000006 R_X86_64_GLOB_DAT      0000000000000000 _ITM_deregisterTMCloneTable + 0
8
0000000000404018  0000000700000005 R_X86_64_COPY          0000000000404018 counter + 0
9

10
Relocation section '.rela.plt' at offset 0x458 contains 2 entries:
11
    Offset             Info             Type               Symbol's Value  Symbol's Name + Addend
12
0000000000404000  0000000300000007 R_X86_64_JUMP_SLOT     0000000000000000 __libc_start_main + 0
13
0000000000404008  0000000400000007 R_X86_64_JUMP_SLOT     0000000000000000 bump + 0
14
$ readelf -sW main_nopie_musl | grep counter
15
     7: 0000000000404018     4 OBJECT  GLOBAL DEFAULT   19 counter
16
    23: 0000000000404018     4 OBJECT  GLOBAL DEFAULT   19 counter

The output now defines a four-byte counter at 0x404018. The library's own GOT reference binds to that executable copy, so all participating references see one object. This is why library-local source syntax did not guarantee library-local storage.

The copy fixes the object's size in the executable's binary interface. Changing the library definition from int counter to long counter grows it from four to eight bytes under this x86-64 ABI. The old executable still reserves four bytes; replacing a library cannot enlarge that allocation.

Loaders can differ in how they diagnose a size mismatch. The following example explicitly builds main_nopie_glibc with the glibc toolchain, links against the original four-byte definition, and then replaces the library. The earlier main_nopie_musl remains a separate musl executable.

1
$ gcc -fPIC -O1 -shared -Wl,-soname,libvec.so.1 vec.c -o libvec.so.1
2
$ gcc -no-pie main_nopic.o -L. -lvec -Wl,-rpath,'$ORIGIN' -o main_nopie_glibc
3
$ ./main_nopie_glibc; echo exit=$?
4
exit=2
5
$ sed 's/int counter;/long counter;/' vec.c > vec8.c
6
$ gcc -fPIC -O1 -shared -Wl,-soname,libvec.so.1 vec8.c -o libvec.so.1
7
$ ./main_nopie_glibc; echo exit=$?
8
./main_nopie_glibc: Symbol `counter' has different size in shared object, consider re-linking
9
exit=2
10
$ ld.lld -shared -soname libvec.so.1 vec.o -o libvec.so.1

The final command restores the original four-byte library definition from the earlier vec.o. The warning identifies an ABI mismatch. An exit status of two does not make the replacement safe: the new library can access eight bytes through storage for which the old executable reserved only four. This is the central cost of a copy relocation: the executable becomes dependent on an object layout that originally belonged to the library.

PIE does not guarantee the absence of copy relocations. Clang normally uses a GOT access here:

1
$ clang -fPIE -O1 -c main.c -o main_pie.o
2
$ llvm-objdump -dr main_pie.o
3
   b:	48 8b 05 00 00 00 00 	mov    0x0(%rip),%rax        # 12 <main+0x12>
4
			e: R_X86_64_REX_GOTPCRELX	counter-0x4
5
  12:	8b 00                	mov    (%rax),%eax
6
$ readelf -r main_pie | grep counter
7
000000003ff0  000200000006 R_X86_64_GLOB_DAT 0000000000000000 counter + 0

The tested GCC instead emits direct PC-relative access and relies on a copy relocation if needed:

1
$ musl-gcc -fPIE -O1 -c main.c -o main_gcc_pie.o
2
$ llvm-objdump -dr main_gcc_pie.o
3
  12:	8b 05 00 00 00 00    	mov    0x0(%rip),%eax        # 18 <main+0x18>
4
			14: R_X86_64_PC32	counter-0x4
5
$ musl-gcc -pie main_gcc_pie.o -L. -lvec -o main_gccpie
6
$ readelf -r main_gccpie | grep counter
7
000000004008  000700000005 R_X86_64_COPY     0000000000004008 counter + 0

The shorter access saves an indirection while retaining the storage-size and binding constraints. Inspect the actual relocation table rather than inferring the behavior from ELF type alone.

A PLT entry can resolve itself on first use

The library's call reaches a generated PLT¹² stub:

1
$ llvm-objdump -d --no-show-raw-insn libvec.so.1
2
0000000000001370 <bump>:
3
    1370:      	pushq	%rax
4
    1371:      	callq	0x13a0 <helper@plt>
5
    1376:      	movq	0x1123(%rip), %rcx      # 0x24a0
6
    ...
7

8
Disassembly of section .plt:
9

10
0000000000001390 <.plt>:
11
    1390:      	pushq	0x211a(%rip)            # 0x34b0
12
    1396:      	jmpq	*0x211c(%rip)           # 0x34b8
13
    139c:      	nopl	(%rax)
14

15
00000000000013a0 <helper@plt>:
16
    13a0:      	jmpq	*0x211a(%rip)           # 0x34c0
17
    13a6:      	pushq	$0x0
18
    13ab:      	jmp	0x1390 <.plt>

1
$ llvm-objdump -s -j .got.plt libvec.so.1
2
Contents of section .got.plt:
3
 34a8 b0230000 00000000 00000000 00000000  .#..............
4
 34b8 00000000 00000000 a6130000 00000000  ................

The initial GOT/PLT area contains a dynamic-table reference, two loader-populated control words, and a function slot that initially routes back into the stub. In the shown traditional glibc protocol:

bump calls helper@plt.
The stub's indirect jump follows its unresolved slot to its own next instruction.
That instruction pushes the relocation index and jumps to PLT0.
PLT0 pushes the module's link_map and enters the runtime resolver.
The resolver preserves call state, finds the named definition, updates the slot, and transfers directly to the function.

Later calls follow the updated slot without repeating lookup. This defers work for unused functions, but leaves writable function slots, delays some missing-symbol errors, and adds first-call latency.

Immediate binding requests all targets before execution proceeds:

1
$ ld.lld -shared -soname libvec.so.1 -z now vec.o -o libvec_now.so
2
$ readelf -d libvec_now.so | grep FLAGS
3
 0x000000000000001e (FLAGS)              BIND_NOW
4
 0x000000006ffffffb (FLAGS_1)            Flags: NOW

-z now sets dynamic flags; LD_BIND_NOW=1 can request the same behavior at runtime. The PLT need not disappear. musl 1.2.5 performs eager binding and does not implement glibc's lazy protocol. -fno-plt goes further by generating a direct GOT-indirect call sequence, trading away lazy binding.

Function addresses need one identity

A non-PIC executable may require a fixed address for a library function before runtime knows its body address. A canonical PLT supplies that identity:

1
$ cat fp.c
2
int bump(int);
3
int (*fp)(int) = bump;
4

5
int main(void) {
6
    return fp(1) + (fp == bump);
7
}
8
$ clang -fno-pic -O1 -c fp.c -o fp.o
9
$ musl-gcc -no-pie fp.o -L. -lvec -o fp_nopie
10
$ readelf --dyn-syms fp_nopie | grep bump
11
     2: 0000000000401030     0 FUNC    GLOBAL DEFAULT  UND bump
12
$ llvm-objdump -d fp_nopie | grep -A1 'bump@plt>:'
13
0000000000401030 <bump@plt>:
14
  401030:	ff 25 d2 2f 00 00    	jmp    *0x2fd2(%rip)        # 404008 <bump>

The executable's dynamic symbol is undefined but has nonzero value 0x401030, its PLT entry. Address-taking lookup can use that value consistently; JUMP_SLOT resolution must still find the actual implementation. This identity contract is separate from when first-call binding happens.

Binding a library's references directly to its body with -Bsymbolic can undermine this arrangement: an address taken inside the library may differ from the executable's canonical address. As with copy relocations, a local optimization interacts with a process-wide identity rule.

Relocate, then remove write access

RELRO¹³ groups data needed writable during relocation but immutable afterward. The static linker describes the range with PT_GNU_RELRO; the loader applies mprotect after completing the required writes.

1
$ readelf -lW libvec.so.1     # default
2
  LOAD      0x0003b0 0x00000000000023b0 ... 0x0000f8 0x000c50 RW  0x1000
3
  LOAD      0x0004a8 0x00000000000034a8 ... 0x000020 0x000024 RW  0x1000
4
  GNU_RELRO 0x0003b0 0x00000000000023b0 ... 0x0000f8 0x000c50 R   0x1
5
   03     .dynamic .got .relro_padding
6
   04     .got.plt .bss
7

8
$ readelf -lW libvec_now.so   # -z now
9
  LOAD      0x0003b0 0x00000000000023b0 ... 0x000138 0x000c50 RW  0x1000
10
  LOAD      0x0004e8 0x00000000000034e8 ... 0x000000 0x000004 RW  0x1000
11
  GNU_RELRO 0x0003b0 0x00000000000023b0 ... 0x000138 0x000c50 R   0x1
12
   03     .dynamic .got .got.plt .relro_padding
13
   04     .bss

With lazy binding, function slots that may still change remain writable: partial RELRO. With immediate binding, they can join the protected range: full RELRO. Padding or layout must make the boundary compatible with page-granular protection. The linker only writes the range description; a runtime startup path must actually enforce it.

Interposition is useful—and it has a cost

For ordinary startup lookup of preemptible globals, the main executable leads, followed by preload/dependency scopes. The first eligible definition wins. Visibility, versions, protected binding, and dlopen scopes constrain this picture; it is not an unconditional rule for every reference.

This allows an application's allocator to serve library callers too, preserving a useful aspect of static-library replacement. Preloading makes the mechanism observable:

1
// fake.c
2
int helper(int x) { return 100; }

1
$ musl-gcc -shared -fPIC fake.c -o libfake.so
2
$ ./main_pie; echo $?; LD_PRELOAD=./libfake.so ./main_pie; echo $?
3
2
4
100

helper is replaced, so bump(1) changes counter to 100 rather than 2. The internal call was deliberately preserved with noinline.

Supporting replacement costs GOT/PLT indirections and constrains optimization. GCC and Clang also differ in how aggressively they optimize same-translation-unit calls under their semantic-interposition policies. Four controls act at different stages:

Hidden visibility narrows the interface before code generation:

1
$ cat vec2.c
2
int counter;
3

4
__attribute__((noinline)) int helper(int x) { return x * 2; }
5

6
__attribute__((visibility("default"))) int bump(int x) {
7
    counter += helper(x);
8
    return counter;
9
}
10
$ clang -fPIC -O1 -fvisibility=hidden -c vec2.c -o vec2.o
11
$ llvm-objdump -d -r --no-show-raw-insn vec2.o
12
0000000000000010 <bump>:
13
      10:      	pushq	%rax
14
      11:      	callq	0x16 <bump+0x6>
15
		0000000000000012:  R_X86_64_PLT32	helper-0x4
16
      16:      	addl	(%rip), %eax            # 0x1c <bump+0xc>
17
		0000000000000018:  R_X86_64_PC32	counter-0x4
18
      1c:      	movl	%eax, (%rip)            # 0x22 <bump+0x12>
19
		000000000000001e:  R_X86_64_PC32	counter-0x4
20
      22:      	popq	%rcx
21
      23:      	retq
22
$ ld.lld -shared -soname libvec.so.1 vec2.o -o libvec2.so
23
$ readelf -r libvec2.so
24
There are no relocations in this file.
25
$ readelf --dyn-syms libvec2.so
26
Symbol table '.dynsym' contains 2 entries:
27
   Num:    Value          Size Type    Bind   Vis      Ndx Name
28
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
29
     1: 00000000000012e0    20 FUNC    GLOBAL DEFAULT    6 bump
30
$ llvm-objdump -d --no-show-raw-insn libvec2.so
31
00000000000012e0 <bump>:
32
    12e0:      	pushq	%rax
33
    12e1:      	callq	0x12d0 <helper>
34
    12e6:      	addl	0x208c(%rip), %eax      # 0x3378 <counter>
35
    12ec:      	movl	%eax, 0x2086(%rip)      # 0x3378 <counter>

Only bump remains exported. Internal accesses become direct, and this tiny library needs no dynamic relocations.

-fno-semantic-interposition permits stronger compiler assumptions while retaining an external interface:

1
$ clang -fPIC -O1 -fno-semantic-interposition -c vec.c -o vec_n.o
2
$ llvm-objdump -d -r --no-show-raw-insn vec_n.o
3
0000000000000010 <bump>:
4
      10:      	pushq	%rax
5
      11:      	callq	0x0 <helper>
6
      16:      	movq	(%rip), %rcx            # 0x1d <bump+0xd>
7
		0000000000000019:  R_X86_64_REX_GOTPCRELX	counter-0x4

The call can use a local alias; the variable still uses the GOT to preserve applicable copy-relocation behavior.

-Bsymbolic acts during linking:

1
$ ld.lld -shared -Bsymbolic vec.o -o libvec_bs.so
2
$ readelf -r libvec_bs.so
3
There are no relocations in this file.
4
$ llvm-objdump -d --no-show-raw-insn libvec_bs.so
5
0000000000001330 <bump>:
6
    1330:      	pushq	%rax
7
    1331:      	callq	0x1320 <helper>
8
    1336:      	leaq	0x208b(%rip), %rcx      # 0x33c8 <counter>
9
    133d:      	addl	(%rcx), %eax

The existing GOT load relaxes to lea, and the PLT disappears. However, binding data to the library's own copy can disagree with an executable's COPY allocation. -Bsymbolic-functions limits the policy to functions, though function-address identity still deserves scrutiny.

A version script can make implementation names local:

1
$ cat vec.map
2
VEC_1.0 {
3
  global: bump; counter;
4
  local: *;
5
};
6
$ ld.lld -shared -soname libvec.so.1 --version-script=vec.map vec.o -o libvec.so.1
7
$ readelf -r libvec.so.1
8
Relocation section '.rela.dyn' at offset 0x2f0 contains 1 entry:
9
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
10
000000002468  000200000006 R_X86_64_GLOB_DAT 0000000000003470 counter@@VEC_1.0 + 0
11
$ llvm-objdump -d --no-show-raw-insn libvec.so.1
12
0000000000001370 <bump>:
13
    1370:      	pushq	%rax
14
    1371:      	callq	0x1360 <helper>

Here helper loses its PLT/relocation while exported counter retains GLOB_DAT. Explicitly declaring the intended interface is often clearer than relying on every global declaration becoming public.

Which calls does an interposer actually intercept?

Compare three ways of counting allocation calls:

1
// hello.c
2
#include <stdio.h>
3
#include <stdlib.h>
4
#include <string.h>
5
#include <malloc.h>
6

7
char *greet(void);              /* defined in static archive libgreet.a */
8

9
int main(void) {
10
    char *p = malloc(10);       /* the application source */
11
    char *s = strdup("hi");     /* malloc called inside libc */
12
    char *g = greet();          /* malloc called inside the static library */
13
    printf("%s %s\n", s, g);
14
    free(p); free(s); free(g);
15
    return 0;
16
}

The direct call is in the main source, greet comes from a static archive, and strdup is in libc. Compile without optimization so deliberately unused allocation/free pairs are not removed.

A macro header changes only source that includes it. --wrap changes undefined references admitted to the current link, including extracted archive members. LD_PRELOAD changes eligible runtime lookup; the wrapper can find the next definition with RTLD_NEXT:

1
// mymalloc_r.c (free follows the same pattern)
2
#define _GNU_SOURCE
3
#include <dlfcn.h>
4
#include "count.h"
5
static void *(*real_malloc)(size_t);
6
void *malloc(size_t n) {
7
    if (!real_malloc) real_malloc = dlsym(RTLD_NEXT, "malloc");
8
    n_malloc++;
9
    return real_malloc(n);
10
}

This is an educational wrapper, not a production allocator bootstrap. dlsym may itself allocate or reenter under other conditions. The accompanying reentry probe happened not to trigger on these two library versions; that does not establish a general guarantee.

The native glibc results are:

1
$ ./hello_c >/dev/null                          # compile-time interception
2
malloc=1 free=3
3
$ ./hello_l >/dev/null                          # link-time interception, dynamic executable
4
malloc=2 free=3
5
$ ./hello_ls >/dev/null                         # link-time interception, static executable
6
malloc=10 free=5
7
$ LD_PRELOAD=./mymalloc.so ./hello_r >/dev/null # load-time interception
8
malloc=4 free=3

The macro sees one allocation and three frees. A dynamically linked --wrap build sees the main call and greet, but not an already-linked libc internal reference. Static wrapping admits libc members too: musl records three allocations/three frees; glibc records ten/five because startup and buffering add activity. The extra allocations were attributed to stdout buffering and the static runtime's loader-support paths. Preloading glibc sees the three requested allocations plus stdout's buffer; musl's fixed stdout buffer leaves three/three.

Scope, not the wrapper's spelling, explains the counts. Statically linked programs do not acquire this preload behavior, locally bound calls bypass ordinary interposition, and secure-execution policy restricts preload use.

A name can have several interface generations

The version script also creates runtime version metadata:

1
$ readelf --dyn-syms libvec.so.1
2
     1: 0000000000001370    19 FUNC    GLOBAL DEFAULT    9 bump@@VEC_1.0
3
     2: 0000000000003470     4 OBJECT  GLOBAL DEFAULT   13 counter@@VEC_1.0
4
$ readelf -V libvec.so.1
5
Version symbols section '.gnu.version' contains 3 entries:
6
 Addr: 0x0000000000000248  Offset: 0x00000248  Link: 1 (.dynsym)
7
  000:   0 (*local*)       2 (VEC_1.0)       2 (VEC_1.0)
8

9
Version definition section '.gnu.version_d' contains 2 entries:
10
 Addr: 0x0000000000000250  Offset: 0x00000250  Link: 6 (.dynstr)
11
  000000: Rev: 1  Flags: BASE  Index: 1  Cnt: 1  Name: libvec.so.1
12
  0x001c: Rev: 1  Flags: none  Index: 2  Cnt: 1  Name: VEC_1.0
13

14
$ musl-gcc -pie main_pie.o -L. -lvec -o main_ver
15
$ readelf -V main_ver
16
Version needs section '.gnu.version_r' contains 1 entry:
17
 Addr: 0x0000000000000400  Offset: 0x00000400  Link: 4 (.dynstr)
18
  000000: Version: 1  File: libvec.so.1  Cnt: 1
19
  0x0010:   Name: VEC_1.0  Flags: none  Version: 2
20
$ readelf --dyn-syms main_ver | grep -E 'bump|counter'
21
     1: 0000000000000000     0 OBJECT  GLOBAL DEFAULT  UND counter@VEC_1.0 (2)
22
     2: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND bump@VEC_1.0 (2)

.gnu.version assigns an index to each dynamic symbol; definition records describe provided versions; need records describe a consumer's requirements. A default definition has @@VERSION; a non-default compatibility definition has @VERSION.

1
$ cat sv.c
2
int bump_v1(int x) { return x; }
3
int bump_v2(int x) { return x * 2; }
4
__asm__(".symver bump_v1, bump@VEC_1.0");
5
__asm__(".symver bump_v2, bump@@VEC_2.0");
6
$ cat sv.map
7
VEC_1.0 { global: bump; local: *; };
8
VEC_2.0 { global: bump; } VEC_1.0;
9
$ clang -fPIC -O1 -c sv.c -o sv.o
10
$ ld.lld -shared --version-script=sv.map sv.o -o libsv.so
11
$ readelf --dyn-syms libsv.so | grep bump
12
     1: 0000000000001320     3 FUNC    GLOBAL DEFAULT    8 bump@VEC_1.0
13
     2: 0000000000001330     4 FUNC    GLOBAL DEFAULT    8 bump@@VEC_2.0

Old clients requesting bump@VEC_1.0 can keep one implementation while newly linked clients select bump@@VEC_2.0. The library need not change SONAME merely to retain both compatible entry points.

glibc's versioned memcpy is a useful historical example: newer default behavior could coexist with an old symbol version mapped to overlap-tolerant compatibility behavior. That preserves a particular old binary contract; it does not make overlapping memcpy valid source code.

The reverse direction fails when a consumer requests a version the installed library never provided:

1
./main: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./main)

This line is illustrative; the locally reproduced version failure appears below. Minimum-runtime support must account for the versions recorded at link time, not just the source APIs used. musl does not implement the same version-selection contract as glibc, so these examples keep the two runtimes distinct.

One loader startup, in order

After receiving AT_PHDR, AT_ENTRY, and AT_BASE, the loader first makes its own early code usable. It then reads the executable's dynamic table, loads preload objects and dependencies, and builds the relevant scopes. Dependency traversal is generally breadth-first for ordinary startup discovery; file identity and aliases also matter, so SONAME is not a universal unique object identifier.

For a dependency name without a slash, glibc's ordinary search order is: applicable RPATH when no RUNPATH supersedes it; LD_LIBRARY_PATH; applicable RUNPATH; loader cache; default directories. RPATH can affect descendants; RUNPATH applies to the requesting object's direct dependencies. Secure execution changes environment handling.

Relocation ordering must make dependencies usable before dependent initialization and copying. Relative relocations need a base; named relocations need scope/version lookup; IFUNC needs its resolver; lazy JUMP_SLOT entries may remain deferred. RELRO protection follows the writes. Shared-library initializers run in dependency order, then startup reaches the executable's entry and libc startup completes the main program's initialization before main. Finalizers unwind the relevant order at shutdown.

Runtime loading repeats much of that work:

1
#include <dlfcn.h>
2
#include <stdio.h>
3

4
int main(void) {
5
    void *h = dlopen("libvec.so.1", RTLD_NOW | RTLD_LOCAL);
6
    if (!h) { fprintf(stderr, "%s\n", dlerror()); return 1; }
7
    int (*bump)(int) = (int (*)(int))dlsym(h, "bump");
8
    printf("%d\n", bump(21));
9
    dlclose(h);
10
    return 0;
11
}

RTLD_NOW requests immediate binding. RTLD_LOCAL keeps the newly loaded group out of the ordinary global export scope; RTLD_GLOBAL exposes it to relevant later lookup. dlsym searches through a handle; GNU dlvsym can request a particular symbol version. dlclose decrements a reference count but does not guarantee immediate unloading when dependencies, NODELETE, or other lifetime rules retain the object.

Stack permissions also cross module boundaries

Handwritten assembly should explicitly state its stack requirements:

1
$ cat fast.s
2
	.text
3
	.globl fast_add
4
	.type fast_add,@function
5
fast_add:
6
	leal (%rdi,%rsi),%eax
7
	ret
8
$ as fast.s -o fast.o
9
$ ld -shared fast.o vec.o -o libmix.so
10
$ readelf -lW libmix.so | grep GNU_STACK
11
  GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0x10
12
$ ld.lld -shared fast.o vec.o -o libmix_lld.so
13
$ readelf -lW libmix_lld.so | grep GNU_STACK
14
  GNU_STACK 0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW 0

The tested mixed inputs produce a non-executable stack with both GNU ld and LLD. Missing-note compatibility defaults depend on target and build configuration; absence is not a portable request for a particular policy.

glibc's loading policy changed in 2.41: a late dlopen cannot simply make all existing thread stacks executable to satisfy a newly loaded object. A request conflicting with the existing stack policy can fail. Startup policy and the documented glibc.rtld.execstack tunable are separate controls; enabling an executable stack at process start is not restoration of the old late-transition behavior. Consult the version-appropriate tunable documentation when investigating such a failure.

Read the binary's expectations before guessing

Use file-inspection tools first:

1
$ llvm-objdump -p main_pie | grep -E 'NEEDED|RPATH|RUNPATH'
2
  NEEDED       libvec.so.1
3
  NEEDED       libc.so
4
  RUNPATH      $ORIGIN
5
$ llvm-objdump -R main_pie | grep RELATIVE | head -2
6
0000000000003dc8 R_X86_64_RELATIVE        *ABS*+0x1150
7
0000000000003dd0 R_X86_64_RELATIVE        *ABS*+0x1110

readelf -d, -r, -V, and --dyn-syms reveal dependencies, relocation jobs, versions, and interfaces. Relocations do not describe every loader action; search paths, initialization, and permission changes have their own metadata.

For a trusted local program, resolved dependencies can be listed with ldd:

1
$ ldd ./main
2
	linux-vdso.so.1 (0x00007d997b25c000)
3
	libvec.so.1 => <work>/ex1/libvec.so.1 (0x00007d997b24a000)
4
	libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007d997b000000)
5
	/lib64/ld-linux-x86-64.so.2 (0x00007d997b25e000)

ldd may involve the runtime loader. Use static inspection such as objdump -p for untrusted files; it reveals direct dependencies without promising a full resolved dependency tree.

glibc's loader explains its own decisions through LD_DEBUG:

1
$ LD_DEBUG=libs ./main
2
   1592030:	find library=libvec.so.1 [0]; searching
3
   1592030:	 search path=<work>/ex1/glibc-hwcaps/x86-64-v3:<work>/ex1/glibc-hwcaps/x86-64-v2:<work>/ex1		(RUNPATH from file ./main)
4
   1592030:	  trying file=<work>/ex1/glibc-hwcaps/x86-64-v3/libvec.so.1
5
   1592030:	    (no such file)
6
   1592030:	  trying file=<work>/ex1/glibc-hwcaps/x86-64-v2/libvec.so.1
7
   1592030:	    (no such file)
8
   1592030:	  trying file=<work>/ex1/libvec.so.1
9
   1592030:
10
   1592030:	find library=libc.so.6 [0]; searching
11
   1592030:	 search path=<work>/ex1		(RUNPATH from file ./main)
12
   1592030:	  trying file=<work>/ex1/libc.so.6
13
   1592030:	    (no such file)
14
   1592030:	 search cache=/etc/ld.so.cache
15
   1592030:	  trying file=/usr/lib/x86_64-linux-gnu/libc.so.6
16
   1592030:
17
   1592030:
18
   1592030:	calling init: /lib64/ld-linux-x86-64.so.2
19
   1592030:
20
   1592030:
21
   1592030:	calling init: /usr/lib/x86_64-linux-gnu/libc.so.6
22
   1592030:
23
   1592030:
24
   1592030:	calling init: <work>/ex1/libvec.so.1
25
   1592030:
26
   1592030:
27
   1592030:	initialize program: ./main
28
   1592030:
29
   1592030:
30
   1592030:	transferring control: ./main
31
   1592030:
32
   1592030:
33
   1592030:	calling fini:  [0]
34
   1592030:
35
   1592030:
36
   1592030:	calling fini: <work>/ex1/libvec.so.1 [0]

libs traces search paths, including hardware-capability subdirectories; bindings identifies chosen definitions; versions checks interface requirements. musl does not supply this glibc debugging facility.

Three locally induced failures distinguish missing file, missing symbol, and missing version:

1
./main: error while loading shared libraries: libvec.so.1: cannot open shared object file: No such file or directory
2
./main: symbol lookup error: ./main: undefined symbol: bump
3
./main_ver: <work>/ex1/libvec.so.1: version `VEC_2.0' not found (required by ./main_ver)

The first two recorded failures exit 127; the version mismatch exits 1. Lazy binding can delay the missing-function failure until its first call. Diagnose the layer that failed rather than treating every case as “the library is missing.”

A call can now cross a module boundary. The next chapter asks how an exception can recover machine state in the opposite direction, back across that same boundary.

Exercises

In a fresh native directory, explicitly select lazy binding—the distribution driver may otherwise request NOW:

1
gcc -O1 -fPIC -shared -Wl,-soname,libvec.so.1 vec.c -o libvec.so.1
2
ln -sf libvec.so.1 libvec.so
3
gcc -O1 main.c -L. -lvec -Wl,-z,lazy -Wl,-rpath,'$ORIGIN' -o main
4
readelf -d main
5
readelf -rW main
6
LD_DEBUG=bindings ./main
7
LD_BIND_NOW=1 LD_DEBUG=bindings ./main

Record dependencies, RUNPATH, counter's relocation, and whether bump/helper bind before or after transferring control. Repeat with LD_BIND_NOW=1.

Compile the following with native GCC -fPIC -O1, then link with ld.lld -shared. Predict counts and targets for RELATIVE, GLOB_DAT, JUMP_SLOT, and symbol-bearing R_X86_64_64. Repeat with { global: use; local: *; };, then with Clang:

1
extern int ext_var;                  /* defined in another module */
2
extern int ext_fn(int);
3
static int priv[8];
4
int pub_var = 1;
5
static int sfn(int x) { return x; }
6
__attribute__((visibility("hidden"))) int hid_fn(int x) { return x + 2; }
7
int pub_fn(int x) { return x + 1; }
8

9
int *p_priv = &priv[3];
10
int *p_pub = &pub_var;
11
int *p_ext = &ext_var;
12
const char *names[] = { "red", "green", "blue" };
13
int (*tbl[])(int) = { sfn, hid_fn, pub_fn, ext_fn };
14

15
int use(int x) { return ext_fn(x) + pub_fn(x) + ext_var + pub_var; }

Preload this deliberately incomplete allocator into a program using strdup, puts, and free. Predict which function fails and why:

1
// fastmalloc.c
2
#include <stddef.h>
3
static char arena[1 << 20];
4
static size_t used;
5
void *malloc(size_t n) {
6
    void *p = arena + used;
7
    used += (n + 15) & ~(size_t)15;
8
    return p;
9
}

Build this using native musl static-PIE startup and libc with musl-gcc -static-pie -fPIE -O1 sp.c -o sp, as in Theory 06. Predict cursor's relocation, inspect all runtime relocation locations, and explain why dynamic relocation tags exist without an interpreter or dependency list:

1
static int table[4] = { 10, 20, 30, 40 };
2
int *cursor = &table[2];
3
int main(void) { return *cursor; }

Answers

1. PIE can still contain COPY

1
0x0000000000000001 (NEEDED)             Shared library: [libvec.so.1]
2
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
3
 0x000000000000001d (RUNPATH)            Library runpath: [$ORIGIN]
4
  [24] .got              PROGBITS        0000000000003fc0 002fc0 000028 08  WA  0   0  8
5
  [25] .got.plt          PROGBITS        0000000000003fe8 002fe8 000020 08  WA  0   0  8
6
  [26] .data             PROGBITS        0000000000004008 003008 000010 00  WA  0   0  8
7

8
Relocation section '.rela.dyn' at offset 0x568 contains 9 entries:
9
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
10
000000003db0  000000000008 R_X86_64_RELATIVE                    1140
11
000000003db8  000000000008 R_X86_64_RELATIVE                    1100
12
000000004010  000000000008 R_X86_64_RELATIVE                    4010
13
000000003fc0  000100000006 R_X86_64_GLOB_DAT 0000000000000000 __libc_start_main@GLIBC_2.34 + 0
14
000000003fc8  000200000006 R_X86_64_GLOB_DAT 0000000000000000 _ITM_deregisterTM[...] + 0
15
000000003fd0  000300000006 R_X86_64_GLOB_DAT 0000000000000000 __gmon_start__ + 0
16
000000003fd8  000400000006 R_X86_64_GLOB_DAT 0000000000000000 _ITM_registerTMCl[...] + 0
17
000000003fe0  000600000006 R_X86_64_GLOB_DAT 0000000000000000 __cxa_finalize@GLIBC_2.2.5 + 0
18
000000004018  000700000005 R_X86_64_COPY     0000000000004018 counter + 0
19

20
Relocation section '.rela.plt' at offset 0x640 contains 1 entry:
21
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
22
000000004000  000500000007 R_X86_64_JUMP_SLO 0000000000000000 bump + 0
23
   1591939:	binding file <work>/ex1/libvec.so.1 [0] to ./main [0]: normal symbol `counter'
24
   1591939:	binding file ./main [0] to <work>/ex1/libvec.so.1 [0]: normal symbol `counter'
25
   1591939:	transferring control: ./main
26
   1591939:	binding file ./main [0] to <work>/ex1/libvec.so.1 [0]: normal symbol `bump'
27
   1591939:	binding file <work>/ex1/libvec.so.1 [0] to <work>/ex1/libvec.so.1 [0]: normal symbol `helper'
28
   1591941:	binding file <work>/ex1/libvec.so.1 [0] to ./main [0]: normal symbol `counter'
29
   1591941:	binding file <work>/ex1/libvec.so.1 [0] to <work>/ex1/libvec.so.1 [0]: normal symbol `helper'
30
   1591941:	binding file ./main [0] to <work>/ex1/libvec.so.1 [0]: normal symbol `counter'
31
   1591941:	binding file ./main [0] to <work>/ex1/libvec.so.1 [0]: normal symbol `bump'
32
   1591941:	transferring control: ./main

NEEDED lists libvec.so.1 and libc.so.6; RUNPATH is $ORIGIN. GCC's direct variable access produces a COPY allocation at 0x4018, and the library binds to that copy. With lazy binding, bump and helper bind after control transfers; NOW moves both earlier. The JUMP_SLOT at 0x4000 and the RELATIVE self-pointer at 0x4010 are different jobs.

2. Classify each use, not merely each name

1
$ musl-gcc -fPIC -O1 -c cnt.c -o cnt_gcc.o
2
$ ld.lld -shared cnt_gcc.o -o libcnt_gcc.so
3
$ readelf -r libcnt_gcc.so | awk '/R_X86/{print $3, $5}' | sort | uniq -c
4
   1 R_X86_64_64 ext_fn
5
   1 R_X86_64_64 ext_var
6
   1 R_X86_64_64 pub_fn
7
   1 R_X86_64_64 pub_var
8
   1 R_X86_64_GLOB_DAT ext_var
9
   1 R_X86_64_GLOB_DAT pub_var
10
   1 R_X86_64_JUMP_SLO ext_fn
11
   1 R_X86_64_JUMP_SLO pub_fn
12
   6 R_X86_64_RELATIVE
13
$ printf '{ global: use; local: *; };\n' > use.map
14
$ ld.lld -shared --version-script=use.map cnt_gcc.o -o libcnt_v.so
15
$ readelf -r libcnt_v.so | awk '/R_X86/{print $3, $5}' | sort | uniq -c
16
   1 R_X86_64_64 ext_fn
17
   1 R_X86_64_64 ext_var
18
   1 R_X86_64_GLOB_DAT ext_var
19
   1 R_X86_64_JUMP_SLO ext_fn
20
   8 R_X86_64_RELATIVE

Six relative pointers cover private data, three strings, a static function, and a hidden function. Four symbol-bearing pointers name public/external data and functions. Code adds two GLOB_DAT entries and two JUMP_SLOT entries. A name used both in data and through a GOT slot can legitimately contribute two relocations.

Localizing pub_var and pub_fn converts their stored pointers to RELATIVE, raising that count to eight. Their code references resolve directly, leaving only external GOT/PLT work. Clang inlines pub_fn into use in this example, so its original JUMP_SLOT count is one rather than GCC's two. Both retain the other classifications.

3. Allocation and deallocation must agree

1
$ LD_PRELOAD=./ex3-gcc/libfast.so LD_DEBUG=bindings ./ex3-gcc/app 2>&1 | grep -E "symbol .(malloc|free|strdup)."
2
1593718:	binding file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] to /usr/lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `free' [GLIBC_2.2.5]
3
   1593718:	binding file /usr/lib/x86_64-linux-gnu/libc.so.6 [0] to ./ex3-gcc/libfast.so [0]: normal symbol `malloc' [GLIBC_2.2.5]
4
   1593718:	binding file ./ex3-gcc/app [0] to /usr/lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `free' [GLIBC_2.2.5]
5
   1593718:	binding file ./ex3-gcc/app [0] to /usr/lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `strdup' [GLIBC_2.2.5]
6
   1593718:	binding file ./ex3-gcc/app [0] to /usr/lib/x86_64-linux-gnu/libc.so.6 [0]: normal symbol `free' [GLIBC_2.2.5]
7
   1593718:	binding file ./ex3-gcc/app [0] to ./ex3-gcc/libfast.so [0]: normal symbol `malloc' [GLIBC_2.2.5]

malloc comes from the interposer, but free still comes from libc and interprets the returned pointer using an unrelated allocator's metadata. glibc aborts with status 134; musl faults with status 139 in these runs. Buffered output is not a reliable indicator of where failure occurred.

The demonstration repair supplies compatible free, calloc, and realloc and then prints hello with status zero on both runtimes. A general replacement also needs correct alignment, bounds/overflow handling, allocation-size tracking, concurrency, and the platform's wider allocator interface. The unbounded bump-pointer snippet is intentionally not a production allocator; see glibc's replacement requirements.

4. Dynamic relocation does not imply shared-library lookup

1
$ musl-gcc -static-pie -fPIE -O1 sp.c -o sp
2
$ readelf -rW sp
3
Relocation section '.rela.dyn' at offset 0x208 contains 5 entries:
4
0000000000003e48  0000000000000008 R_X86_64_RELATIVE 14c0
5
0000000000003e50  0000000000000008 R_X86_64_RELATIVE 1480
6
0000000000003ff0  0000000000000008 R_X86_64_RELATIVE 3e58
7
0000000000004000  0000000000000008 R_X86_64_RELATIVE 4000
8
0000000000004020  0000000000000008 R_X86_64_RELATIVE 4018
9
$ nm sp | grep -wE 'cursor|table'
10
0000000000004020 D cursor
11
0000000000004010 d table
12
$ ./sp; echo exit=$?
13
exit=30

The five sites belong to initializer/finalizer arrays, GOT, __dso_handle, and cursor. table=0x4010; adding eight gives the cursor addend 0x4018. Native execution returns 30 after startup adds the chosen base. The executable needs self-relocation metadata, not an external interpreter or dependency.

With load bias B, startup writes B+0x4018 at B+0x4020, allowing main to read 30 through cursor. Linking determines the target's position within the image; startup supplies B without looking up a definition in another library.

Here .dynamic describes relocation metadata rather than external dependencies. rcrt1.o uses _DYNAMIC to find that metadata and relocates the image before entering ordinary C startup. The kernel establishes mappings; it does not apply this table. Function pointers in initialization and finalization arrays have the same requirement, so one cursor in the source does not imply one runtime relocation in the executable. The count depends on the startup and library contents; explaining each destination is more useful than memorizing five entries.

References and terminology

ELF dynamic structures, x86-64 psABI, and ld.so(8).
musl design, runtime differences, dlopen, and ldd.
Ulrich Drepper, How To Write Shared Libraries and ELF Symbol Versioning.
The interception exercise follows the compile/link/load comparison in CMU 15-213.

Appendix: terms and tools

musl is a C-library implementation for Linux, providing standard functions and runtime support. We use it when inspecting or linking a compact static runtime; an ordinary Linux server need not have it installed. Project. ↩
glibc, the GNU C Library, is the default C library in many Linux distributions. Startup files, shared libraries, and the dynamic linker all participate in building and running programs. Project. ↩
GCC, the GNU Compiler Collection, provides compilers for several languages. The gcc command is a driver that coordinates compilation, assembly, and linking; it need not perform all those operations in one process. Overall options. ↩
GNU is the recursive acronym “GNU's Not Unix,” the name of the free-software operating-system project. GCC, binutils, and glibc are distinct GNU projects with different responsibilities. GNU's introduction. ↩
GNU binutils includes the assembler as, linker ld, and inspection or archive utilities such as readelf, nm, objdump, and ar. Documentation. ↩
musl-gcc wraps GCC with musl-specific header and linking settings. It is not inherently a cross-compiler; options such as -static determine the requested linkage. Getting started with musl. ↩
PIC, position-independent code, uses addressing suited to placement at varying load addresses. It is common in shared libraries; the exact use of PC-relative access or indirection depends on the architecture and symbol binding. GCC code-generation options. ↩
GOT, the Global Offset Table, stores addresses or related offsets used through indirection. It lets some address-dependent updates happen in data rather than instruction bytes; relocation types and the ABI define each entry's role. Dynamic linking. ↩
ELF, the Executable and Linkable Format, specifies object files, executables, and shared objects. The gABI supplies generic rules; a processor-specific ABI supplies architecture-dependent rules such as relocation encodings. ELF specification. ↩
PIE, a position-independent executable, can run at different load bases. Compiler and linker choices must cooperate; static PIE also needs a startup path that performs its required relocations. GCC link options. ↩
TLS, Thread-Local Storage, gives each thread its own instance of a variable. The linker describes an initialization template and processes access models; the runtime establishes per-thread instances. This is unrelated to Transport Layer Security. ELF TLS design. ↩
PLT, the Procedure Linkage Table, contains instruction sequences used as call stubs, often together with the GOT and dynamic symbol binding. It is not merely another table of addresses. Dynamic linking. ↩
RELRO, RELocation Read-Only, protects memory that needs relocation-time writes but should become read-only afterward. PT_GNU_RELRO describes the range; the startup path must enforce the protection. GNU ld options. ↩