[The World of Linkers—Theory 02] An Object File Is a Program with Unfinished Business

main.c can compile without add.c. That convenience creates a file-format obligation: main.o must preserve the call's machine code and enough information to finish the call later. A list of bytes cannot explain which name is missing, which field needs changing, or which calculation belongs there.

The file also has to distinguish executable instructions, writable variables, read-only constants, and information used only by tools. A large zero-initialized array should not require a large run of zero bytes on disk. An ELF¹ object is therefore both compiled material and a structured handoff.

This chapter follows that handoff from assembly directives to raw ELF bytes, explaining how ELF preserves code, data, names, and unfinished address calculations. The examples use little-endian x86-64 ELF64; generic file structures and architecture-specific encodings are treated separately.

Follow an entry from the file to its payload

The first row is one contiguous file. The ELF header locates the whole section table: e_shoff=256, e_shnum=3, and e_shstrndx=2. Each entry occupies e_shentsize=64 bytes. Entry 1 starts at 256 + 1 * 64 = 320, so its descriptor occupies [320,384). Reading that entry's sh_offset=64 and sh_size=128 then identifies the .text payload at [64,192). Each of those fields occupies 8 bytes; the stored value describes a different region. Every entry shares the same 64-byte layout, with special SHT_NULL semantics for entry zero.

Names are not inline in the headers. e_shstrndx selects the header describing .shstrtab; that header locates the name bytes. Each entry's sh_name is an offset into those bytes. Keep the two origins distinct: sh_offset is relative to the file start, whereas sh_name is relative to the string-table start.

The section table need not be last, and payload order can differ from table order. SHT_NOBITS, commonly used for .bss, describes memory without storing payload bytes. Three headers take 192 bytes even in this tiny example, so the table can be larger than the payloads it describes.

Start before the object file exists

Use two source files. The caller contains several kinds of storage so that the resulting sections have something concrete to describe:

1
// main.c
2
int add(int a, int b);
3

4
int counter = 42;
5
int zeros[64];
6
const int table[4] = {1, 2, 3, 4};
7
const char *msg = "hello";
8

9
int main(void) {
10
    return add(counter, table[2]) * 2;
11
}

1
// add.c
2
int add(int a, int b) {
3
    return a + b;
4
}

The command name cc² does not identify a particular implementation. Here we select Clang explicitly and ask it to show the compilation phases:

1
$ clang -O1 -ccc-print-phases -c add.c
2
         +- 0: input, "add.c", c
3
      +- 1: preprocessor, {0}, cpp-output
4
   +- 2: compiler, {1}, ir
5
+- 3: backend, {2}, assembler
6
4: assembler, {3}, object

Preprocessing expands includes and macros. The compiler produces IR³, optimization works on that representation, the backend selects target instructions, and assembly forms the object file. Save the intermediate products to inspect them:

1
$ clang -O1 -save-temps -c add.c
2
$ ls add.*
3
add.bc  add.c  add.i  add.o  add.s

The .i file is preprocessed C, .bc is LLVM⁴ bitcode, .s is assembly text, and .o is the object. These files make the stages visible; they are not proof that every ordinary compilation writes each intermediate file. Clang can use an integrated assembler. GCC⁵ commonly invokes as⁶, with a temporary file or a pipe carrying assembly between stages.

The generated add.s, with a few incidental comments removed, is short:

1
	.file	"add.c"
2
	.text
3
	.globl	add
4
	.p2align	4
5
	.type	add,@function
6
add:
7
	.cfi_startproc
8
	leal	(%rdi,%rsi), %eax
9
	retq
10
.Lfunc_end0:
11
	.size	add, .Lfunc_end0-add
12
	.cfi_endproc
13
	.ident	"Ubuntu clang version 21.1.8 (6ubuntu1)"
14
	.section	".note.GNU-stack","",@progbits
15
	.addrsig

Only leal and retq are CPU instructions. In this AT&T syntax, the destination operand is on the right. The x86-64 calling convention supplies the first integer arguments in the argument registers; the result is returned in %eax.

The other lines tell the assembler how to organize the file. A label assigns a name to the current location. .file records a source filename. .ident supplies a compiler-identification string. .cfi_* describes unwind state. .addrsig requests address-significance metadata used when deciding whether merging functions would alter observable address identity. Their consumers differ, even though they arrive in one assembly stream.

The assembler has a current section and a current offset

A useful working model is a collection of growing buffers, one per section. An instruction appends its encoding to the current buffer. A data directive appends data. A label records a section and an offset. Switching away from a section and later returning resumes that same section; it does not create a new copy.

Write an object directly in assembly to see the model without C in front of it:

1
# hand.S: construct an object directly
2
        .section .text,"ax",@progbits
3
        .globl  add
4
        .type   add,@function
5
add:
6
        leal    (%rdi,%rsi), %eax
7
        ret
8
        .size   add, . - add
9

10
        .section .data,"aw",@progbits
11
        .balign 4
12
        .globl  answer
13
        .type   answer,@object
14
answer:
15
        .long   42
16
        .size   answer, 4
17

18
        .section .rodata,"a",@progbits
19
greeting:
20
        .asciz  "hi"
21
        .byte   0xff
22
        .balign 8
23
        .uleb128 624485
24
        .sleb128 -123456
25

26
# Macro: substitute the parameters \name and \value
27
        .macro  CONST name, value
28
        .globl  \name
29
\name:
30
        .long   \value
31
        .endm
32

33
#ifdef BIG
34
        CONST   limit, 100000
35
#else
36
        CONST   limit, 100
37
#endif
38

39
        .section .note.GNU-stack,"",@progbits

The main directives express different kinds of information:

For the section flags, a means allocated at runtime, w writable, and x executable instructions. @progbits stores contents in the file; @nobits describes storage without corresponding contents. Usual .text, .data, and .bss directives select conventional sections with appropriate defaults. See the assembler's section directive documentation for the complete rules.

In .size add, . - add, both locations belong to the same section, so their difference is the function length. The CPU does not read that size to execute ret; tools use it to identify the function's range.

Alignment can add bytes without adding a source-level object. Data padding here is zero; code alignment may use NOP encodings. The macro body substitutes \name and \value at each invocation. CONST limit, 100 emits a global label followed by a four-byte integer; it does not create a runtime macro mechanism.

For the first pass, retain three ideas: sections group contents, labels name section offsets, and alignment can add padding. The LEB128 and preprocessing directives in hand.S are explained in the optional section near the end.

Which references can the assembler finish?

Knowing that a label occurs in this source file does not always mean its address can be committed now. Consider a local function, a public function, and a global variable:

1
// calls.c
2
static __attribute__((noinline)) int helper(int x) { return x * 3; }
3
__attribute__((noinline)) int pub(int x) { return x + 1; }
4
int count;
5

6
int caller(int x) {
7
    return helper(x) + pub(x) + count;
8
}

noinline keeps the calls visible for inspection. Add -r to disassembly so relocation records appear beside their fields:

1
$ clang -O1 -c calls.c -o calls.o
2
$ llvm-objdump -dr calls.o
3
[excerpt]
4
0000000000000010 <caller>:
5
      10: 55                           	pushq	%rbp
6
      11: 53                           	pushq	%rbx
7
      12: 50                           	pushq	%rax
8
      13: 89 fb                        	movl	%edi, %ebx
9
      15: e8 26 00 00 00               	callq	0x40 <helper>
10
      1a: 89 c5                        	movl	%eax, %ebp
11
      1c: 89 df                        	movl	%ebx, %edi
12
      1e: e8 00 00 00 00               	callq	0x23 <caller+0x13>
13
		000000000000001f:  R_X86_64_PLT32	pub-0x4
14
      23: 01 e8                        	addl	%ebp, %eax
15
      25: 03 05 00 00 00 00            	addl	(%rip), %eax            # 0x2b <caller+0x1b>
16
		0000000000000027:  R_X86_64_PC32	count-0x4
17
[excerpt]
18
0000000000000040 <helper>:
19
      40: 8d 04 7f                     	leal	(%rdi,%rdi,2), %eax
20
      43: c3                           	retq

The call to helper already has displacement 0x26: the next instruction is at 0x1a, and 0x1a + 0x26 = 0x40. Moving the entire .text section preserves that distance. The call to pub retains a relocation, as does the access to count.

A forward reference such as helper requires layout before final encoding. Even layout can require iteration on x86 because jumps have short and long forms:

1
$ cat jmp100.s
2
        .text
3
        jmp     .Ldone
4
        .fill   100, 1, 0x90
5
.Ldone:
6
        ret
7
$ clang -c jmp100.s -o jmp100.o
8
$ llvm-objdump -d jmp100.o | grep -E 'jmp|ret'
9
       0: eb 64                        	jmp	0x66 <.text+0x66>
10
      66: c3                           	retq

A jump over 100 bytes fits the short form eb 64. Change the gap to 200 and the assembler needs the five-byte form e9 c8 00 00 00; the destination itself consequently moves. Multiple branches and alignment directives can influence one another. Iteration finds a stable layout before final fixups are applied.

The assembler initially represents unresolved expressions as fixups. After layout, it can evaluate an expression, reject an invalid expression, or emit a relocation for the linker. Three cases explain this example:

• A same-section relative reference with established local binding can become a constant displacement.
• A reference across sections needs their eventual relative placement, even if the target is local.
• A reference through a global or weak name may require the linker's binding decision, even if a definition is currently visible in the same section.

Give every function its own section and the local call now needs a relocation too:

1
$ clang -O1 -ffunction-sections -c calls.c -o calls-fs.o
2
$ llvm-objdump -dr calls-fs.o | grep -A1 'callq'
3
       5: e8 00 00 00 00               	callq	0xa <caller+0xa>
4
		0000000000000006:  R_X86_64_PLT32	.text.helper-0x4
5
--
6
       e: e8 00 00 00 00               	callq	0x13 <caller+0x13>
7
		000000000000000f:  R_X86_64_PLT32	pub-0x4

The reference to helper is expressed as a section symbol plus an offset. Public pub retains its name because symbol resolution and interposition can determine a different binding. By contrast, a same-section difference used for .size can still be evaluated even when one endpoint has global binding: it describes this assembled range.

The rule is about what remains undecided, not whether a human can see both labels in the file.

Read the header before interpreting the contents

Keep a map in view: the ELF header locates the section-header table; section headers identify contents and byte ranges; .symtab gets names through .strtab; relocation entries refer to symbol-table indices. Each field below describes either a range, a name, or a relationship between tables.

Compile the original inputs:

1
$ clang -O1 -c main.c -o main.o
2
$ clang -O1 -c add.c -o add.o
3
$ file main.o add.o
4
main.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
5
add.o:  ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped

file identifies class, byte order, machine, and relocatable type from the header. For deeper inspection, GNU readelf⁷ prints ELF fields directly; llvm-objdump is especially useful for disassembly; nm⁸ focuses on symbols. Independent readers help cross-check an interpretation. The short Python reader below is an explanatory tool for this known ELF64 little-endian input, not a hardened parser for arbitrary files.

The first 64 bytes are the ELF64 header:

1
$ xxd -l 64 main.o
2
00000000: 7f45 4c46 0201 0100 0000 0000 0000 0000  .ELF............
3
00000010: 0100 3e00 0100 0000 0000 0000 0000 0000  ..>.............
4
00000020: 0000 0000 0000 0000 e002 0000 0000 0000  ................
5
00000030: 0000 0000 4000 0000 0000 4000 0f00 0100  ....@.....@.....

The ELF64 structure Elf64_Ehdr occupies 64 bytes; the ELF Header specification defines its fields. The gABI defines the generic file structures, while a psABI⁹ supplies processor-specific conventions. Class and byte order come from the file's e_ident, rather than from the machine running the parser.

The first 16 bytes, e_ident, can be interpreted before word size or byte order is known. The remaining multibyte fields follow the byte order it specifies. This table accounts for all 64 bytes; offsets are relative to the file start, widths describe the fields themselves, and values are decoded from the example above.

The two version fields are distinct: EI_VERSION at offset 6 is one byte, while e_version at offset 20 is four bytes. Both contain EV_CURRENT=1 here. Likewise, e_ehsize=64 describes the file header and e_shentsize=64 describes one section header. Equal sizes do not make them the same structure. With ordinary numbering, section indices start at zero and must be less than e_shnum.

Ordinary section counts are below SHN_LORESERVE=0xff00. At that threshold, e_shnum holds zero and section zero's sh_size carries the actual count; the large count is not stored directly in the 16-bit field. A name-table index at the same threshold uses SHN_XINDEX=0xffff in e_shstrndx and section zero's sh_link for the actual index. See the gABI ELF header definition.

ELF also permits an absent section table, an absent section-name table, and extended numbering. A zero e_shnum can indicate no table or require the actual count to be read from entry zero's sh_size; when e_shstrndx=SHN_XINDEX, entry zero's sh_link holds the actual index. A parser can explicitly support only a subset of these encodings without declaring the other encodings invalid ELF.

Other familiar types include ET_EXEC and ET_DYN; the latter covers shared objects and PIE¹⁰ executables. Table location, entry count, and the contents described by those entries remain separate concepts.

The section header table ends at $736+15\times64=1696$, exactly the recorded file size:

1
$ wc -c main.o
2
1696 main.o

Proving that a table range can be read

A table position does not prove its bytes exist. Treat a file of length L as a byte sequence and use half-open intervals [offset, end): the start is included, the end is excluded, and the length is end − offset. Reading s bytes at o requires calculating end = o + s without overflow, then proving end ≤ L. With a nonnegative size and valid addition, the start is also within the file. The empty interval [L,L) is valid; [L+1,L+1) is outside the file despite containing no bytes.

The table length is entry count × entry width, not just the count. Here 15 × 64 = 960 bytes, so the table occupies [736,1696). Checking only 736 + 15 ≤ L establishes at most the first fifteen bytes, not fifteen complete headers.

Selecting entry i requires two independent checks:

1. i < e_shnum: the index belongs to this table. Additional file bytes cannot turn the following content into another table entry.
2. The entire interval [e_shoff + i × e_shentsize, e_shoff + (i+1) × e_shentsize) lies within the file. A valid index can still refer to truncated input.

Validation of another byte sequence does not establish these facts if the caller supplies a shorter input or constructs a table position itself. Perform arithmetic in a type wide enough for file coordinates. The count and ordinary index fields occupy two bytes, but multiplication need not use a 16-bit type: 1024 × 64 = 65536 cannot be represented in u16. Widen before multiplying rather than reporting a valid count as overflow.

Arithmetic overflow and file bounds are different failures. At offset u64::MAX − 63, a 128-byte table has a mathematical end beyond u64::MAX; addition cannot express its range. At offset 160 with length 64 in a 192-byte file, the end 224 is representable but outside the file. Casting a large offset to host usize first can truncate high bits on a narrower machine and turn an invalid position into an apparently readable small index. Prove the range first, then use checked conversions.

Range checks establish safe reading, not correct record semantics. Name indices, symbol-table associations, and relocation ownership need their own validation; the following sections explain those relationships.

The header summary and empty execution view agree:

1
$ llvm-objdump -f main.o
2

3
main.o:	file format elf64-x86-64
4
architecture: x86_64
5
start address: 0x0000000000000000

1
$ llvm-objdump -p main.o
2

3
main.o:	file format elf64-x86-64
4

5
Program Header:
6

7
Dynamic Section:

The section view, however, is already populated:

1
$ llvm-objdump -h main.o
2

3
main.o:	file format elf64-x86-64
4

5
Sections:
6
Idx Name            Size     VMA              Type
7
  0                 00000000 0000000000000000
8
  1 .strtab         000000a1 0000000000000000
9
  2 .text           00000015 0000000000000000 TEXT
10
  3 .rela.text      00000030 0000000000000000
11
  4 .data           00000010 0000000000000000 DATA
12
  5 .rela.data      00000018 0000000000000000
13
  6 .rodata         00000010 0000000000000000 DATA
14
  7 .rodata.str1.1  00000006 0000000000000000 DATA
15
  8 .bss            00000100 0000000000000000 BSS
16
  9 .comment        00000028 0000000000000000
17
 10 .note.GNU-stack 00000000 0000000000000000
18
 11 .eh_frame       00000030 0000000000000000 DATA
19
 12 .rela.eh_frame  00000018 0000000000000000
20
 13 .llvm_addrsig   00000000 0000000000000000
21
 14 .symtab         000000f0 0000000000000000

Zero section virtual addresses are expected here: these input sections have not received final runtime placement.

Section headers describe relationships as well as ranges

Each section header uses the 64-byte Elf64_Shdr layout. Offsets here are relative to the beginning of that entry, rather than to the beginning of the file.

To locate entry i, calculate e_shoff + i × e_shentsize. Read the descriptor there, then use its sh_offset and sh_size to locate its payload. A NOBITS descriptor gives a memory requirement without supplying that many bytes in the file. Symbol and relocation tables also require following associations such as sh_link, as the next sections explain.

This Python reader explains a known-valid ELF64 little-endian input. It does not fully validate table bounds, extended numbering, string termination, or associated indices. A general-purpose parser must validate these conditions before performing the same lookups:

1
import struct, sys
2

3
data = open(sys.argv[1], "rb").read()
4
# ELF64: e_shoff at 0x28; e_shentsize/e_shnum/e_shstrndx at 0x3a
5
shoff = struct.unpack_from("<Q", data, 0x28)[0]
6
shentsize, shnum, shstrndx = struct.unpack_from("<HHH", data, 0x3a)
7

8
TYPES = {0: "NULL", 1: "PROGBITS", 2: "SYMTAB", 3: "STRTAB", 4: "RELA",
9
         8: "NOBITS", 0x70000001: "X86_64_UNWIND", 0x6fff4c03: "LLVM_ADDRSIG"}
10
FLAGS = [(0x1, "W"), (0x2, "A"), (0x4, "X"), (0x10, "M"), (0x20, "S"), (0x40, "I")]
11

12
def shdr(i):
13
    # sh_name, sh_type, sh_flags, sh_addr, sh_offset, sh_size,
14
    # sh_link, sh_info, sh_addralign, sh_entsize
15
    return struct.unpack_from("<IIQQQQIIQQ", data, shoff + i * shentsize)
16

17
names_off = shdr(shstrndx)[4]
18
def name(off):
19
    end = data.index(b"\0", names_off + off)
20
    return data[names_off + off:end].decode()
21

22
print("Nr Name             Type          Flg Off    Size   Lk Inf Al ES")
23
for i in range(shnum):
24
    n, t, f, _, off, size, link, info, align, es = shdr(i)
25
    flg = "".join(c for bit, c in FLAGS if f & bit)
26
    print(f"{i:2} {name(n):16} {TYPES.get(t, hex(t)):13} {flg:3} "
27
          f"{off:06x} {size:06x} {link:2} {info:3} {align:2} {es:2}")

The format <IIQQQQIIQQ selects little-endian integers with the widths required by the ELF64 structure. The result is:

1
$ python3 shdr.py main.o
2
Nr Name             Type          Flg Off    Size   Lk Inf Al ES
3
 0                  NULL              000000 000000  0   0  0  0
4
 1 .strtab          STRTAB            000238 0000a1  0   0  1  0
5
 2 .text            PROGBITS      AX  000040 000015  0   0 16  0
6
 3 .rela.text       RELA          I   0001d8 000030 14   2  8 24
7
 4 .data            PROGBITS      WA  000058 000010  0   0  8  0
8
 5 .rela.data       RELA          I   000208 000018 14   4  8 24
9
 6 .rodata          PROGBITS      A   000070 000010  0   0 16  0
10
 7 .rodata.str1.1   PROGBITS      AMS 000080 000006  0   0  1  1
11
 8 .bss             NOBITS        WA  000090 000100  0   0 16  0
12
 9 .comment         PROGBITS      MS  000090 000028  0   0  1  1
13
10 .note.GNU-stack  PROGBITS          0000b8 000000  0   0  1  0
14
11 .eh_frame        X86_64_UNWIND A   0000b8 000030  0   0  8  0
15
12 .rela.eh_frame   RELA          I   000220 000018 14  11  8 24
16
13 .llvm_addrsig    LLVM_ADDRSIG      000238 000000 14   0  1  0
17
14 .symtab          SYMTAB            0000e8 0000f0  1   4  8 24

Types describe representation. PROGBITS stores ordinary contents; NOBITS reserves storage without contents; SYMTAB, STRTAB, and RELA identify structured tables. X86_64_UNWIND is a processor-specific type used for unwind information. LLVM_ADDRSIG is an LLVM extension supporting decisions about observable address identity, including safe ICF¹¹.

Flags express other properties:

Thus .text is AX, .data and .bss are WA, and .rodata is A. Nonallocated tables serve tools rather than becoming ordinary mapped program storage.

.bss has size 0x100 for zeros[64], yet shares file offset 0x90 with the following .comment. No 256-byte file range is consumed by its storage. The assembler describes the reservation; the linker ultimately expresses the zero-filled runtime tail through segment sizes. With the toolchain's -fno-common behavior, this tentative C definition already belongs to .bss; common symbols are the next chapter's topic.

The relationships in sh_link and sh_info depend on section type. .rela.text links to symbol table 14 and targets section 2. .rela.data targets section 4. .rela.eh_frame targets section 11. .symtab links to string table 1; its info value 4 marks the first nonlocal symbol. Do not interpret all sh_info fields as section indices.

Section zero is SHT_NULL. It is all zero in this file, but large files may use it to hold extended numbering information. Likewise, the name .shstrtab is a convention rather than a requirement: LLVM here shares .strtab between section names and symbol names. Follow indices instead of guessing relationships from names.

1
$ llvm-objdump -s -j .strtab main.o
2

3
main.o:	file format elf64-x86-64
4
Contents of section .strtab:
5
 0000 002e7265 6c612e74 65787400 2e636f6d  ..rela.text..com
6
 0010 6d656e74 002e6273 73007a65 726f7300  ment..bss.zeros.
7
 0020 636f756e 74657200 6d61696e 002e6e6f  counter.main..no
8
 0030 74652e47 4e552d73 7461636b 006d7367  te.GNU-stack.msg
9
 0040 002e6c6c 766d5f61 64647273 6967002e  ..llvm_addrsig..
10
 0050 72656c61 2e65685f 6672616d 65007461  rela.eh_frame.ta
11
 0060 626c6500 61646400 6d61696e 2e63002e  ble.add.main.c..
12
 0070 73747274 6162002e 73796d74 6162002e  strtab..symtab..
13
 0080 726f6461 7461002e 72656c61 2e646174  rodata..rela.dat
14
 0090 61002e72 6f646174 612e7374 72312e31  a..rodata.str1.1
15
 00a0 00                                   .

A string table is a byte sequence of zero-terminated names, referenced by byte offset. counter starts at 0x20, main at 0x28, and add at 0x64. A name may begin inside another stored string: .text starts at offset 6, inside .rela.text. This suffix sharing is legal because the index identifies bytes, not a numbered string record.

Match the stored bytes to the source

Generate main.s with clang -O1 -S main.c. Its data directives expose the intended organization:

1
	.type	counter,@object
2
	.data
3
	.globl	counter
4
	.p2align	2, 0x0
5
counter:
6
	.long	42
7
	.size	counter, 4
8
	.type	table,@object
9
	.section	.rodata,"a",@progbits
10
	.globl	table
11
	.p2align	4, 0x0
12
table:
13
	.long	1
14
	.long	2
15
	.long	3
16
	.long	4
17
	.size	table, 16
18
	.type	.L.str,@object
19
	.section	.rodata.str1.1,"aMS",@progbits,1
20
.L.str:
21
	.asciz	"hello"
22
	.size	.L.str, 6
23
	.type	msg,@object
24
	.data
25
	.globl	msg
26
	.p2align	3, 0x0
27
msg:
28
	.quad	.L.str
29
	.size	msg, 8
30
	.type	zeros,@object
31
	.bss
32
	.globl	zeros
33
	.p2align	4, 0x0
34
zeros:
35
	.zero	256
36
	.size	zeros, 256

Returning to .data appends msg after counter and alignment padding. The generated code is:

1
$ llvm-objdump -d main.o
2

3
main.o:	file format elf64-x86-64
4

5
Disassembly of section .text:
6

7
0000000000000000 <main>:
8
       0: 50                           	pushq	%rax
9
       1: 8b 3d 00 00 00 00            	movl	(%rip), %edi            # 0x7 <main+0x7>
10
       7: be 03 00 00 00               	movl	$0x3, %esi
11
       c: e8 00 00 00 00               	callq	0x11 <main+0x11>
12
      11: 01 c0                        	addl	%eax, %eax
13
      13: 59                           	popq	%rcx
14
      14: c3                           	retq

table[2] became immediate 3. The compiler knew the const array's value and eliminated the load. The push and pop maintain the call-site stack alignment; they are not preserving a meaningful C variable here. The two zero displacement fields still await linking.

1
$ llvm-objdump -s -j .data main.o
2

3
main.o:	file format elf64-x86-64
4
Contents of section .data:
5
 0000 2a000000 00000000 00000000 00000000  *...............

The first four data bytes encode 42, the next four are padding, and the final eight are the unresolved pointer msg. Declaring const char *msg makes the pointed-to characters const; it does not make the pointer object itself const.

The ordinary read-only section holds the four integers of table. The string has a separate mergeable-string input section with one-byte character units. The linker may combine identical strings, which is why references to pieces of mergeable sections require care.

1
$ llvm-objdump -s -j .bss main.o
2
[file header omitted]
3
Contents of section .bss:
4
<skipping contents of bss section at [0000, 0100)>

No .bss bytes are available to dump. The version string does have file contents but no allocation flag:

1
$ llvm-objdump -s -j .comment main.o
2

3
main.o:	file format elf64-x86-64
4
Contents of section .comment:
5
 0000 00556275 6e747520 636c616e 67207665  .Ubuntu clang ve
6
 0010 7273696f 6e203231 2e312e38 20283675  rsion 21.1.8 (6u
7
 0020 62756e74 75312900                    buntu1).

.note.GNU-stack is another useful contrast: it has no contents and no allocation flag, yet communicates a requirement used in producing the executable. .eh_frame does have allocated contents and its own relocations, because unwind records must refer to the final code ranges.

A symbol record is more than a name

1
$ llvm-objdump -t main.o
2

3
main.o:	file format elf64-x86-64
4

5
SYMBOL TABLE:
6
0000000000000000 l    df *ABS*	0000000000000000 main.c
7
0000000000000000 l    d  .text	0000000000000000 .text
8
0000000000000000 l    d  .rodata.str1.1	0000000000000000 .rodata.str1.1
9
0000000000000000 g     F .text	0000000000000015 main
10
0000000000000000 g     O .data	0000000000000004 counter
11
0000000000000000         *UND*	0000000000000000 add
12
0000000000000000 g     O .rodata	0000000000000010 table
13
0000000000000008 g     O .data	0000000000000008 msg
14
0000000000000000 g     O .bss	0000000000000100 zeros

Every ELF64 symbol occupies 24 bytes:

1
typedef struct {
2
    Elf64_Word    st_name;   /* 4 bytes: name offset in the linked string table */
3
    unsigned char st_info;   /* 1 byte: binding in high nibble, type in low nibble */
4
    unsigned char st_other;  /* 1 byte: includes visibility (Theory 03) */
5
    Elf64_Half    st_shndx;  /* 2 bytes: section index */
6
    Elf64_Addr    st_value;  /* 8 bytes: value; normally a section offset in ET_REL */
7
    Elf64_Xword   st_size;   /* 8 bytes: size */
8
} Elf64_Sym;

The table contains ten records, including the reserved all-zero entry that this objdump listing omits. Inspect its encoding:

1
$ llvm-objdump -s -j .symtab main.o
2

3
main.o:	file format elf64-x86-64
4
Contents of section .symtab:
5
 0000 00000000 00000000 00000000 00000000  ................
6
 0010 00000000 00000000 68000000 0400f1ff  ........h.......
7
 0020 00000000 00000000 00000000 00000000  ................
8
 0030 00000000 03000200 00000000 00000000  ................
9
 0040 00000000 00000000 00000000 03000700  ................
10
 [intermediate rows omitted]
11
 0060 28000000 12000200 00000000 00000000  (...............
12
 0070 15000000 00000000 20000000 11000400  ........ .......
13
 0080 00000000 00000000 04000000 00000000  ................
14
 0090 64000000 10000000 00000000 00000000  d...............
15
 00a0 00000000 00000000 5e000000 11000600  ........^.......
16
 [remaining output omitted]

At offset 0x60, symbol 4 has name offset 0x28 (main), info 0x12, section index 2, value zero, and size 0x15. Split st_info into high and low nibbles: binding 1 is STB_GLOBAL; type 2 is STT_FUNC. Its value is a section-relative offset in this relocatable file, not a final process address.

Binding controls participation in name resolution. Local symbols belong to one input. Global symbols participate across inputs. Weak definitions have lower precedence than ordinary global definitions. This small example makes the categories visible:

1
// bind.c
2
static int hits;                         /* local to this input */
3
__attribute__((weak)) int hook(void) {   /* weak definition; a strong definition can replace it */
4
    return 0;
5
}
6
extern int maybe(void) __attribute__((weak));  /* weak reference */
7

8
int poke(void) {
9
    hits++;
10
    return hook() + (maybe ? maybe() : 0) + hits;
11
}

1
$ clang -O1 -c bind.c -o bind.o
2
$ llvm-objdump -t bind.o
3

4
bind.o:	file format elf64-x86-64
5

6
SYMBOL TABLE:
7
0000000000000000 l    df *ABS*	0000000000000000 bind.c
8
0000000000000000 l    d  .text	0000000000000000 .text
9
0000000000000000 l     O .bss	0000000000000004 hits
10
0000000000000000 l    d  .bss	0000000000000000 .bss
11
0000000000000000  w    F .text	0000000000000003 hook
12
0000000000000010 g     F .text	000000000000002b poke
13
0000000000000000  w      *UND*	0000000000000000 maybe

The C static object becomes a local symbol. hook is a weak definition; maybe is a weak undefined reference. The compiler emits .weak to express those bindings in assembly. The handwritten object's symbols provide another comparison:

1
$ llvm-objdump -t hand-small.o
2

3
hand-small.o:	file format elf64-x86-64
4

5
SYMBOL TABLE:
6
0000000000000000 l       .rodata	0000000000000000 greeting
7
0000000000000000 g     F .text	0000000000000004 add
8
0000000000000000 g     O .data	0000000000000004 answer
9
000000000000000e g       .rodata	0000000000000000 limit

Without .type or .size, a symbol can remain STT_NOTYPE with size zero and still be useful for linking. Those missing attributes reduce what debuggers or profiling tools can infer about its extent.

File symbols use STT_FILE and the special SHN_ABS index. Section symbols use STT_SECTION; their stored name can be empty even when an inspection tool displays the associated section's name. They let relocations describe a local location without a global name lookup:

1
$ llvm-objdump -dr bind.o
2
[excerpt]
3
0000000000000010 <poke>:
4
      10: 53                           	pushq	%rbx
5
      11: ff 05 00 00 00 00            	incl	(%rip)                  # 0x17 <poke+0x7>
6
		0000000000000013:  R_X86_64_PC32	.bss-0x4
7
[remaining output omitted]

The reference to local hits becomes .bss plus the appropriate offset. A compiler-private .L label can similarly disappear from the symbol table when a section-relative expression represents it adequately. As the exercises show, references into mergeable sections can require retaining such a label.

For add, st_shndx = SHN_UNDEF records the missing definition. NOTYPE in that record does not mean the C compiler forgot that add was declared as a function; it means this ELF record does not specify a symbol type. nm makes the unfinished relationship particularly clear:

1
$ nm main.o
2
                 U add
3
0000000000000000 D counter
4
0000000000000000 T main
5
0000000000000008 D msg
6
0000000000000000 R table
7
0000000000000000 B zeros

1
$ llvm-objdump -t add.o
2

3
add.o:	file format elf64-x86-64
4

5
SYMBOL TABLE:
6
0000000000000000 l    df *ABS*	0000000000000000 add.c
7
0000000000000000 l    d  .text	0000000000000000 .text
8
0000000000000000 g     F .text	0000000000000004 add

The definition in add.o supplies the section, value, type, and size. Local records precede global and weak records in the ELF table. The .symtab header's sh_info = 4 therefore lets the linker skip directly to the first nonlocal record when building its global resolution table.

A relocation is a request, not a search for zero bytes

Now inspect the instructions together with their pending requests:

1
$ llvm-objdump -dr main.o
2
[file header omitted]
3
0000000000000000 <main>:
4
       0: 50                           	pushq	%rax
5
       1: 8b 3d 00 00 00 00            	movl	(%rip), %edi            # 0x7 <main+0x7>
6
		0000000000000003:  R_X86_64_PC32	counter-0x4
7
       7: be 03 00 00 00               	movl	$0x3, %esi
8
       c: e8 00 00 00 00               	callq	0x11 <main+0x11>
9
		000000000000000d:  R_X86_64_PLT32	add-0x4
10
      11: 01 c0                        	addl	%eax, %eax
11
      13: 59                           	popq	%rcx
12
      14: c3                           	retq

The field for counter starts at .text+3; the call field starts at .text+0xd. Listing all relocations also reveals the pointer and unwind reference:

1
$ llvm-objdump -r main.o
2

3
main.o:	file format elf64-x86-64
4

5
RELOCATION RECORDS FOR [.text]:
6
OFFSET           TYPE                     VALUE
7
0000000000000003 R_X86_64_PC32            counter-0x4
8
000000000000000d R_X86_64_PLT32           add-0x4
9

10
RELOCATION RECORDS FOR [.data]:
11
OFFSET           TYPE                     VALUE
12
0000000000000008 R_X86_64_64              .rodata.str1.1
13

14
RELOCATION RECORDS FOR [.eh_frame]:
15
OFFSET           TYPE                     VALUE
16
0000000000000020 R_X86_64_PC32            .text

An Elf64_Rela contains three eight-byte fields: r_offset, r_info, and signed r_addend. The relocation section's own header identifies the target section and symbol table. Decode the two text records:

1
$ llvm-objdump -s -j .rela.text main.o
2

3
main.o:	file format elf64-x86-64
4
Contents of section .rela.text:
5
 0000 03000000 00000000 02000000 05000000  ................
6
 0010 fcffffff ffffffff 0d000000 00000000  ................
7
 0020 04000000 06000000 fcffffff ffffffff  ................

The first r_info is 0x0000000500000002: symbol index 5 (counter) in the upper half and type 2 (R_X86_64_PC32) in the lower half. Its addend is −4. The next record names symbol 6 (add), uses type 4 (R_X86_64_PLT32), and has the same addend.

Read each record as a concrete request:

• At .text+3, write the appropriate four-byte relative value for counter with addend −4.
• At .text+0xd, write the call displacement for add, subject to the binding rules of PLT32.
• At .data+8, write the eight-byte address of the beginning of .rodata.str1.1.
• In .eh_frame, repair the reference identifying the code range.

The zero bytes in these examples are placeholders. A linker does not scan for zeros and guess which ones are missing addresses. Records identify the fields and formulas, and some relocation formats take an addend from the existing field itself. Before evaluating a name-based relocation, the linker must decide which definition that name denotes.

Linking adds the loader's view

Sections provide the detailed units used in construction. Segments describe how to establish the runtime image. To see both views in one file, provide a minimal entry point without a C runtime:

1
# start.S: entry without a C runtime
2
        .text
3
        .globl  _start
4
_start:
5
        call    main
6
        movl    %eax, %edi      # use the return value of main as the exit status
7
        movl    $60, %eax       # 60 is the x86-64 Linux exit syscall number
8
        syscall
9
        .section .note.GNU-stack,"",@progbits

Link the three objects and inspect the result:

1
$ clang -c start.S -o start.o
2
$ ld.lld -o prog start.o main.o add.o
3
$ readelf -lW prog
4

5
Elf file type is EXEC (Executable file)
6
Entry point 0x2011d0
7
There are 5 program headers, starting at offset 64
8

9
Program Headers:
10
  Type           Offset   VirtAddr           PhysAddr           FileSiz  MemSiz   Flg Align
11
  PHDR           0x000040 0x0000000000200040 0x0000000000200040 0x000118 0x000118 R   0x8
12
  LOAD           0x000000 0x0000000000200000 0x0000000000200000 0x0001c4 0x0001c4 R   0x1000
13
  LOAD           0x0001d0 0x00000000002011d0 0x00000000002011d0 0x000034 0x000034 R E 0x1000
14
  LOAD           0x000208 0x0000000000202208 0x0000000000202208 0x000010 0x000118 RW  0x1000
15
  GNU_STACK      0x000000 0x0000000000000000 0x0000000000000000 0x000000 0x000000 RW  0
16

17
 Section to Segment mapping:
18
  Segment Sections...
19
   00
20
   01     .rodata .eh_frame
21
   02     .text
22
   03     .data .bss
23
   04

Each ELF64 program header is a 56-byte Elf64_Phdr. Offsets below are relative to the start of the current entry; widths describe the fields themselves:

The p_filesz field always occupies eight bytes. A value of 16 describes sixteen payload bytes; field width and represented size are different quantities. Entry i starts at e_phoff + i × e_phentsize. Its p_offset points to content elsewhere in the file: the entry itself is not that content. Segment permissions differ from section SHF_* flags: RX is 5, while a code section's ALLOC|EXECINSTR is 6.

For PT_LOAD, file offset and virtual address describe the mapping, file and memory sizes distinguish stored bytes from total storage, and alignment constrains their relationship. PT_PHDR describes the program header table itself, while PT_GNU_STACK communicates stack permissions without describing a mapped file payload.

This output groups read-only constants and unwind data in an R segment, code in an RE segment, and writable data plus zero-filled storage in an RW segment. The RW segment has file size 0x10 but memory size 0x118. The latter includes the gap before the aligned .bss and its 256 bytes: .bss ends at 0x202320, and subtracting the segment base 0x202208 gives 0x118.

The input relocations have been applied and their tables are absent from this particular output. That is not a rule that executables never contain relocations: dynamic linking and --emit-relocs provide obvious counterexamples. The loader needs the program headers to establish the image; it does not need the detailed input-section history.

We can now identify an object file's unfinished work directly. The next chapter examines the first decision needed to finish it: choosing definitions when several inputs offer, request, or weakly reference the same name.

Optional detour: compact integers and assembly preprocessing

The main ELF walkthrough is complete. Return to hand.S here to inspect its variable-length integers and preprocessing; neither is required to follow the first header, symbol, or relocation record.

Small integers deserve small encodings

Fixed-width .long uses four bytes whether the value is 3 or a million. Metadata often contains many small integers and only occasional large ones. LEB128¹² uses seven payload bits per byte, with bit 7 indicating whether another byte follows. Low-order groups come first.

For unsigned 624485:

1. The low seven bits are 0x65; more remain, so emit 0xe5.
2. The next group is 0x0e; more remain, so emit 0x8e.
3. The final group is 0x26; emit it without the continuation bit.

The result is e5 8e 26. Signed LEB128 stops when the remaining high bits are all sign bits and bit 6 of the final payload agrees with that sign. For −123456, the groups produce c0 bb 78; the decoder sign-extends from the final group's bit 6. Merely reaching a remaining value of −1 is not sufficient unless the emitted group's sign bit agrees.

DWARF 5, section 7.6 specifies these encodings. They also appear in WebAssembly and DEX, so recognizing them pays off beyond ELF.

Inspect the assembled read-only data:

1
$ clang -c hand.S -o hand-small.o
2
$ llvm-objdump -s -j .rodata hand-small.o
3

4
hand-small.o:	file format elf64-x86-64
5
Contents of section .rodata:
6
 0000 686900ff 00000000 e58e26c0 bb786400  hi........&..xd.
7
 0010 0000                                 ..

Offsets 0–2 hold hi and a zero terminator. Offset 3 holds ff. Four padding bytes advance the next value to offset 8. The two LEB128 values occupy three bytes each, and the macro's integer begins at offset 0xe. Its 64 00 00 00 is the little-endian encoding of 100. Total size: 0x12 bytes.

Uppercase .S requests preprocessing

The #ifdef belongs to the C preprocessor, not the assembler's macro system. Driver conventions normally preprocess .S before assembly; lowercase .s normally skips that step. Define BIG to select the other macro invocation:

1
$ clang -DBIG -c hand.S -o hand-big.o
2
$ llvm-objdump -s -j .rodata hand-big.o
3

4
hand-big.o:	file format elf64-x86-64
5
Contents of section .rodata:
6
 0000 686900ff 00000000 e58e26c0 bb78a086  hi........&..x..
7
 0010 0100                                 ..

The final integer changes to a0 86 01 00, or 100000. Now deliberately use the lowercase suffix:

1
$ cp hand.S plain.s
2
$ clang -DBIG -c plain.s -o plain.o
3
clang: warning: argument unused during compilation: '-D BIG' [-Wunused-command-line-argument]
4
<instantiation>:2:1: error: symbol 'limit' is already defined
5
limit:
6
^

The unused-option warning tells us preprocessing did not occur. In this x86 assembly syntax, lines beginning with # are comments, so both CONST invocations remain and both define limit. Explicitly selecting the language restores preprocessing:

1
$ clang -x assembler-with-cpp -DBIG -c plain.s -o plain.o
2
$ llvm-objdump -s -j .rodata plain.o | tail -2
3
 0000 686900ff 00000000 e58e26c0 bb78a086  hi........&..x..
4
 0010 0100                                 ..

Kernel and runtime assembly often uses .S to share constants and select architecture features. Whatever the source-level machinery, the linker receives the resulting object file.

Exercises

1. Predict the symbol table

Compile with clang -O0 -c quiz.c, but classify the source names before inspecting the object:

1
// quiz.c
2
int printf(const char *fmt, ...);
3
extern int limit;
4
extern int unused;
5
int total = 0;
6
__attribute__((weak)) int verbose = 1;
7
static int square(int v) { return v * v; }
8

9
int report(int n) {
10
    static int calls;
11
    int sum = square(n) + total + limit;
12
    if (verbose) printf("%d: %d\n", ++calls, sum);
13
    return sum;
14
}

For printf, limit, unused, total, verbose, square, v, report, n, calls, sum, and the string literal, predict whether an ELF symbol appears. For each that does, predict binding, type, and definition section or undefined status. Check with readelf -sW quiz.o, then repeat at -O1.

2. Predict every fixup

1
# predict.s
2
        .text
3
        .globl  entry
4
        .type   entry,@function
5
entry:
6
        movl    counter(%rip), %eax
7
        call    bump
8
        call    ext_func
9
        leaq    .Lmsg(%rip), %rdi
10
        jmp     .Lout
11
.Lout:
12
        ret
13
        .size   entry, . - entry
14

15
        .section .text.cold,"ax",@progbits
16
bump:
17
        ret
18

19
        .data
20
        .globl  counter
21
counter:
22
        .long   7
23
        .long   .Lout - entry
24
slot:
25
        .quad   counter + 8
26
        .quad   slot
27

28
        .section .rodata.str1.1,"aMS",@progbits,1
29
.Lmsg:
30
        .asciz  "ok"
31
        .section .note.GNU-stack,"",@progbits

List the sections, symbols, and relocation records before assembling. For each relocation give the target section, field offset, type, symbol, and addend. Which expressions can the assembler finish? The RIP-relative movl prefix occupies two bytes, call one, and the leaq prefix three. Assemble with Clang and GNU as; identify the relocation type that differs.

3. Change permissions without changing instructions

1
        .section .boot,"ax",@progbits
2
        .globl  _start
3
_start:
4
        movl    $60, %eax
5
        movl    $42, %edi
6
        syscall
7
        .section .note.GNU-stack,"",@progbits

Assemble and link with LLD and GNU ld, then run natively:

1
$ ./prog; echo $?

After observing 42 with "ax", try "a" and "x". Predict linker diagnostics, program headers, entry address, and runtime behavior. Restore "ax" afterward.

Answers and recorded results

1. Source names and linker symbols are different sets

1
$ clang -O0 -c quiz.c -o quiz.o
2
$ readelf -sW quiz.o
3

4
Symbol table '.symtab' contains 12 entries:
5
   Num:    Value          Size Type    Bind   Vis      Ndx Name
6
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
7
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS quiz.c
8
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    2 .text
9
     3: 0000000000000060    16 FUNC    LOCAL  DEFAULT    2 square
10
     4: 0000000000000004     4 OBJECT  LOCAL  DEFAULT    4 report.calls
11
     5: 0000000000000000     8 OBJECT  LOCAL  DEFAULT    6 .L.str
12
     6: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 .bss
13
     7: 0000000000000000    87 FUNC    GLOBAL DEFAULT    2 report
14
     8: 0000000000000000     4 OBJECT  GLOBAL DEFAULT    4 total
15
     9: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND limit
16
    10: 0000000000000000     4 OBJECT  WEAK   DEFAULT    5 verbose
17
    11: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND printf

printf and limit are global undefined symbols. unused is only a declaration and produces no reference. total is a global object in .bss, despite explicitly spelling its zero initializer. verbose is a weak object in .data. square is a local function; report a global function. The function-local static becomes local object report.calls in .bss; unlike an automatic variable, it has persistent storage.

Parameters v and n, and automatic sum, do not become ordinary linker symbols. Their register or stack locations belong to individual calls and, when available, debug descriptions. “Local symbol” and “local C variable” describe different concepts.

The string appears here as local .L.str. The PC-relative reference has addend −4 and targets a mergeable-string section. Replacing that reference naively with a section symbol plus an offset can lose the association with the correct string when pieces are merged. The assembler retains the label. The earlier absolute reference with zero addend could be represented through the section symbol. GCC's placement into ordinary .rodata produces a different representation again. Predict from the actual relocation and section properties, not from a blanket rule that all .L names disappear.

At -O1, square is inlined and its standalone symbol disappears in the recorded result.

2. Six relocations, two resolved expressions

1
$ clang -c predict.s -o predict.o
2
$ readelf -sW predict.o
3

4
Symbol table '.symtab' contains 9 entries:
5
   Num:    Value          Size Type    Bind   Vis      Ndx Name
6
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND
7
     1: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    4 bump
8
     2: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT    7 .Lmsg
9
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    4 .text.cold
10
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    5 .data
11
     5: 0000000000000008     0 NOTYPE  LOCAL  DEFAULT    5 slot
12
     6: 0000000000000000    26 FUNC    GLOBAL DEFAULT    2 entry
13
     7: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT    5 counter
14
     8: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND ext_func
15
$ llvm-objdump -dr predict.o
16
[file header omitted]
17
0000000000000000 <entry>:
18
       0: 8b 05 00 00 00 00            	movl	(%rip), %eax            # 0x6 <entry+0x6>
19
		0000000000000002:  R_X86_64_PC32	counter-0x4
20
       6: e8 00 00 00 00               	callq	0xb <entry+0xb>
21
		0000000000000007:  R_X86_64_PLT32	.text.cold-0x4
22
       b: e8 00 00 00 00               	callq	0x10 <entry+0x10>
23
		000000000000000c:  R_X86_64_PLT32	ext_func-0x4
24
      10: 48 8d 3d 00 00 00 00         	leaq	(%rip), %rdi            # 0x17 <entry+0x17>
25
		0000000000000013:  R_X86_64_PC32	.Lmsg-0x4
26
      17: eb 00                        	jmp	0x19 <entry+0x19>
27
      19: c3                           	retq
28
[excerpt]
29
$ llvm-objdump -r predict.o | tail -4
30
RELOCATION RECORDS FOR [.data]:
31
OFFSET           TYPE                     VALUE
32
0000000000000008 R_X86_64_64              counter+0x8
33
0000000000000010 R_X86_64_64              .data+0x8
34
$ llvm-objdump -s -j .data predict.o | tail -2
35
 0000 07000000 19000000 00000000 00000000  ................
36
 0010 00000000 00000000                    ........

The content sections are .text (0x1a bytes), .text.cold (one byte), .data (0x18), .rodata.str1.1 (three), and the empty stack note. Symbol, string, and relocation tables accompany them. Additional empty or property sections vary with the assembler and its configuration.

entry is a global function of size 26. counter is global but has no explicit type or size. ext_func is undefined. bump and slot are local. .Lmsg is retained for the mergeable-section reference; .Lout is unnecessary as a stored symbol. Section symbols describe local relocation targets.

The short jump to the following instruction is already eb 00. The same-section difference .Lout - entry is 0x19, stored at .data+4 as 19 00 00 00.

GNU as uses PC32 for the local cross-section call:

1
$ as predict.s -o predict-gas.o
2
$ llvm-objdump -dr predict-gas.o | grep -A1 'callq'
3
       6: e8 00 00 00 00               	callq	0xb <entry+0xb>
4
		0000000000000007:  R_X86_64_PC32	.text.cold-0x4
5
--
6
       b: e8 00 00 00 00               	callq	0x10 <entry+0x10>
7
		000000000000000c:  R_X86_64_PLT32	ext_func-0x4

Because that local target cannot bind through a shared-library PLT, the two recorded relocation types lead to the same displacement in this case. Their general semantics still differ.

3. Successful linking does not prove executable permissions

1
$ ld.lld -o lld-ax flag-ax.o; ld -o gnu-ax flag-ax.o
2
$ readelf -lW lld-ax | grep -E 'Entry|LOAD'
3
Entry point 0x201120
4
  LOAD           0x000000 0x0000000000200000 0x0000000000200000 0x000120 0x000120 R   0x1000
5
  LOAD           0x000120 0x0000000000201120 0x0000000000201120 0x00000c 0x00000c R E 0x1000
6
$ readelf -lW lld-a | grep -E 'Entry|LOAD'
7
Entry point 0x200120
8
  LOAD           0x000000 0x0000000000200000 0x0000000000200000 0x00012c 0x00012c R   0x1000
9
$ readelf -lW lld-x | grep -E 'Entry|LOAD'
10
Entry point 0x0
11
  LOAD           0x000000 0x0000000000200000 0x0000000000200000 0x000120 0x000120 R   0x1000
12
$ readelf -lW gnu-x | grep -E 'Entry|LOAD'
13
Entry point 0x0

With "ax", both linkers place .boot in an executable load segment and both native executions return 42. With "a", both links succeed without warning, but the entry is in a read-only, non-executable mapping. Execution fails with SIGSEGV; the recorded shell status is 139.

With "x", the section lacks allocation. It is absent from PT_LOAD, and the recorded entry address is zero. LLD retains a header-only read-only load segment; GNU ld emits no load segment. Both recorded native executions fail with SIGSEGV and shell status 139. The exact entry and layout are observations of these versions, while the underlying mistake is the missing allocation requirement.

A linker organizes sections according to their declared properties. It does not infer that bytes resembling instructions must be executable. The object file is a contract, including the parts its author got wrong.

References and terminology

The ELF section specification, symbol-table specification, GNU assembler manual, LLVM toolchain description, and DWARF 5 standard define the structures and encodings used here. The symbol-classification exercise follows the teaching pattern used in CMU 15-213; Princeton COS 217's assembler/linker material offers a complementary introduction to fixups.