CODEWITHSUNDEEP
cobjectlinkerrelocation
Multisync
Multisync

Reputation: 823

How to read the relocation records of an object file

I'm trying to understand the linking stage of C toolchain. I wrote a sample program and dissected the resulting object file. While this helped me to get a better understanding of the processes involved, there are some things which remain unclear to me.

Here are:

Part 1: Handling of initialized variables.

Is it correct, that theses relocation table entries...

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
0000002b dir32             .data
00000035 dir32             .data
0000003f dir32             .data

... are basically telling the linker, that the addresses stored at offset 2b, 35 and 3f from .text are not absolute adresses, but relative adresses (= offsets) in relation to .data? It is my understanding that this enables the linker to

Part 2: Handling of uninitialized variables.

I don't understand why uninitalized variables are handled so differently to initialized variables. Why are the register adresses stored in the opcode,

Also the value field of their relocation table entries is entirely unclear to me. I would have expected the .bss section to be referenced there.

RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE              VALUE
0000000d dir32             _var1_zeroed-0x00000004
00000017 dir32             _var2_zeroed-0x00000004
00000021 dir32             _var3_zeroed-0x00000004

Upvotes: 7

Views: 3604

Answers (1)

Hans Passant
Hans Passant

Reputation: 942187

... are basically telling the linker, that the addresses stored at offset ...

No, the linker is no longer involved with this. The relocation tables tell the loader, the part of the operating system that's responsible for loading the executable image into memory about the addresses.

The linker builds the executable image based on the assumption that everything is ideal and the image can be loaded at the intended address. If that's the case then everything is hunky-dory, nothing needs to be done. If there's a conflict however, the virtual address space is already in use by something else, then the image needs to be relocated at a different address.

That requires addresses to be patched, the offset between the ideal and the actual load address needs to be added. So if the .data section ends up at another address then addresses .text+0x2b, .text+0x35, etcetera, must be changed. No different for the uninitialized variables, the linker already picked an address for them but when _var1_zeroed-0x00000004 ends up at another address then .text+0x0d, .text+0x17, etcetera, need to be changed.

Upvotes: 3

Related Questions