Exercise 3: Resolving main.asm's Cross-File Reference For Real — Possible Solution
====================================================================

RECAP OF THE SCENARIO (from assembly1-1's Exercise 2)
------------------------------
main.asm contains a reference to a label that is only defined inside
helper.asm -- the two files are assembled and linked together into
one final program.

WHAT main.asm's OWN PASS 1 AND PASS 2 DO
------------------------------
main.asm is assembled entirely on its own, independently of
helper.asm. Its own Pass 1 scans only main.asm's source and builds a
symbol table containing only the labels DEFINED inside main.asm --
the external label from helper.asm never gets added to it, because
Pass 1 has no visibility into helper.asm's contents at all.

When main.asm's own Pass 2 reaches the instruction referencing that
external label, it looks the label up in its own (incomplete, from a
whole-program perspective) symbol table and doesn't find it. Per this
chapter's own "Object Files & the Linker" section, the assembler
doesn't fail outright -- instead, it records that specific reference
as UNRESOLVED, tagged as an external reference, inside main.asm's
resulting object file. The instruction's own offset field is left as
a placeholder rather than a real, final value.

WHAT main.asm's OBJECT FILE CONTAINS FOR THAT REFERENCE
------------------------------
main.asm's object file contains: the (mostly complete) machine code
for main.asm itself, PLUS a record noting "this specific instruction
still needs an address for an external symbol named X, which this
file does not define." That record is exactly the information the
linker will need later.

WHAT THE LINKER DOES TO RESOLVE IT
------------------------------
Per the chapter's own description, the linker reads BOTH object
files -- main.asm's and helper.asm's. It collects helper.asm's own
exported symbols (which include the label main.asm needs), and
matches that against main.asm's own list of unresolved external
references. Once it finds the match, it computes the real, final
address for that label (based on where helper.asm's code actually
ends up in the combined executable image) and patches that address
directly into the placeholder left in main.asm's machine code. Once
every unresolved reference across both object files has been matched
and patched this way, the linker produces one single, fully-resolved
executable image with no unresolved references left anywhere --
ready for the loader, per assembly1-1's own pipeline.

WHY THIS WORKS AS AN ANSWER
------------------------------
It walks through main.asm's own Pass 1/Pass 2 explicitly showing why
the external label can't be resolved locally, names precisely what
gets recorded in the object file as a result (an unresolved external
reference, not a guess or an error), and describes the linker's
actual resolution mechanism (matching against helper.asm's exported
symbols and patching the real address in) rather than treating
"linking" as a black box.