On 29/05/2016 04:39 AM, clipka wrote:
> 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.

Oh, I see. So, what, the jump op-code says to jump to address zero, and 
the object metadata tells the linker which bytes to change?

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

Don't you start. I've already spent a day looking at the output of nm, 
objdump and readelf. :-P The manpages tell you what all the switches do, 
but I still have no idea what .text is supposed to mean.

>> 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.

Hmm. Interesting.

   extern const unsigned char font_timrom[36936]={...

I didn't think you could make an array const. (Wouldn't that just mean 
the array pointer itself is constant? Not the array it points to.) And I 
thought extern means "this is declared somewhere else"?

[Also... Heh, do you know, when you said it, I was thinking I'd be able 
to browse the source online somewhere. Silly me...]

Post a reply to this message