Am 28.05.2016 um 09:47 schrieb Orchid Win7 v1:

> But how does that actually *work*? The C compiler transforms C source
> code into executable object code. Basically, the object file contains
> (among other things) raw machine code, which the processor knows how to
> execute. Calling a subroutine is implemented as an unconditional jump
> op-code. If you know the jump target, then by all means, fill in the
> target address. But if the target hasn't been resolved yet... how do you
> fit the entire symbol name into 32 bits?

Simple: You don't.

Instead, you add a table to the library listing all the memory locations
that should hold the address of a given unresolved symbol but for
obvious reasons currently don't.

The linker will later use that table to update those memory locations.


> (32 bits is only 4 characters. And C++ in particular seems determined to
> transform even the most trivial function call into an 8-mile symbol name!)
> 
> Presumably the object file contains some metadata too. Stuff that tells
> you it *is* an object file, what the target processor is, what symbols
> it exposes publicly, etc. But I'm not sure how unresolved function calls
> are implemented.

You /could/ look it up... you know, they have this fancy new thing
called the Internet, and search engines and things ;)


> For that matter, how does the linker sort all this out? Does it actually
> load the entire final binary into memory while it untangles it? Or does
> it somehow manage to incrementally build the file on disk? [I guess it's
> perhaps implementation-defined...] My Linux box is sitting here with
> 16GB of RAM, and can probably handle holding the whole 0.2MB program in
> RAM at once. The original 2KB system that C was designed for? Not so much.

[Your guess is correct.]


> For that matter, is it possible to store *data* in an object file? (As
> opposed to executable code.)

Absolutely. See the `source/base/font/*.cpp` files in the POV-Ray source
code for examples.

Post a reply to this message