Question bank — Object files — .o - .obj, symbol table, relocation entries

False. It contains real opcodes but with placeholder address bytes — any call or global reference is a zero waiting to be patched via a relocation, so it is machine code with holes, not finished code.

False. .bss stores only a size number, not the zeros themselves; the OS zero-fills that region at load time, so int big[1000000]; adds ~0 bytes to the file. See Sections — .text .data .bss .rodata.

Mostly true, but incomplete. Beyond DEFINED vs UND there are also LOCAL symbols (file-private labels) and WEAK symbols (defined but overridable), so "provide/need" is the global-binding view, not the whole table.

False. A symbol entry names who a location is; a relocation entry names which bytes to patch and how — it merely references a symbol by index. One symbol can have many relocations pointing at it.

False. Many files may reference the same undefined symbol; the linker resolves all of them against the single definition (in libc). Two definitions would be the error, not two references.

False. U in a lone .o is normal — it just means "not defined here." It only becomes a problem if no linked object or library ever supplies a definition.

False. The addend (typically -4) is precisely the negative distance from the patch slot $P$ to the next-instruction address, so the stored displacement $S+A-P$ lands the branch exactly on the symbol. See PC-relative addressing in x86-64.

False. There is no entry point (_start), library symbols are unresolved, and relocations are unpatched; jumping into it crashes. Only the Linker — symbol resolution and relocation step makes it executable.

False. They are different container formats — ELF and COFF file formats differ in headers, section layout, and relocation-type encodings — though both play the same role in the pipeline.

False. Absolute writes $S+A$ (the address itself); PC-relative writes $S+A-P$ (a distance). They differ by $P$, the location of the patch slot, so only in the impossible case $P=0$ would they coincide.

Error: that confuses compile-time and link-time. A missing header is a compiler error (no declaration); undefined reference is a linker error meaning the declaration existed but no .o/library defined the symbol. Fix by adding the source file or -l library.

Error: file-scope int x; is a global tentative definition, so you have two globals with the same name — a multiple-definition link error (or silent "common" merge, a classic bug). Use static for file-local or one extern to share.

Error: the .o is emitted by the assembler with placeholders still in place; patching happens later, in the linker, once every section has a final address. That ordering is exactly why relocations must exist.

Error: the relocation stores a type and a symbol reference, not the address — the linker computes the value with the type's formula ($S+A$ or $S+A-P$) using addresses it chooses at link time.

Error: PC32 is PC-relative, so its formula is $S+A-P$. Dropping the $-P$ would make the call jump to an address that is off by the patch-slot's own position.

Error: a weak symbol is used if no strong definition exists; it is only overridden when a strong (GLOBAL) definition of the same name appears. It is a fallback, not an ignore flag.

Because it compiles one file in isolation and cannot know where other .o files and libraries will be laid out; guessing would break the moment layout changed, so it defers to the linker via relocations — enabling separate compilation.

The CPU computes the target as next-instruction-address + displacement, and the 4 displacement bytes sit between the patch slot $P$ and that next address; -4 cancels that gap so $S+A-P$ points exactly at the target.

Because overloading lets many functions share a source name (f(int), f(double)), but a symbol table needs unique names; mangling encodes the signature into the symbol so the linker can tell them apart.

PC-relative displacements stay valid when the whole section is moved as a block, which makes position-independent code and shared libraries possible — see Static vs Dynamic Linking.

Because each file compiles to an independent .o with a self-describing symbol/relocation to-do list; only the changed .o is rebuilt and the project is re-linked, which is the whole economic point of object files.

Possibly none — if all its calls are within the same section and resolved by the assembler, no linker patch is required; only cross-section or external references generate relocation entries.

Zero (or undefined), because the file provides no bytes for it — the value only becomes meaningful once the linker resolves the symbol against a defining object.

Yes — a function that calls itself, or a global used in the same file that declares it, appears once as DEFINED while relocations reference that same symbol index; definition and reference are independent facts.

A multiple-definition error, because the linker must match each reference to exactly one definition; two strong definitions of the same name are ambiguous and rejected.

undefined reference at link time — the "looking-for" badge finds no matching "can-provide," so the linker cannot patch that relocation and refuses to produce an executable.

.bss — an explicit zero initialiser is equivalent to no initialiser for storage purposes, so the compiler stores only its size, saving 400 bytes of file space.