Page 1 of 1

Relocation when binary get loaded.

Posted: Sat Jan 31, 2015 10:57 pm
by HyperAssembler
Hi guys,
So I've been using grub to load my kernel which is compiled and linked as binary.

It suddenly came to me today that binary does not have symbol table, nor can you specify where to load the kernel in grub, how can a arbitrarily-loaded kernel still address itself correctly?

For instance,

Code: Select all

msg:
db  'abcde';
mov eax,msg ; This should behave differently depending on where the binary kernel is loaded, since the address of msg is determined after being linked to binary.
push eax
call print_str
add esp,4
My first thought was PC-relative(RIP-relative) addressing.
So basically everything is the offset relative to its current address.
Then I looked up intel manual and found out that MOV is actually absolute-addressing.

I also tried to specify different base addresses in linker script (one 0x0, the other one 0x10000)
and they exhibited the exact same behavior in bochs.

And now it's confusing the hell out of me. Could someone please clear this up for me?

Thank you for your time!!

Re: Relocation when binary get loaded.

Posted: Sat Jan 31, 2015 11:01 pm
by HyperAssembler
And I did compare the binary output for different org address.
They are DIFFERENT.

Re: Relocation when binary get loaded.

Posted: Sun Feb 01, 2015 12:40 am
by alexfru
In 16-bit and 32-bit modes only memory locations in direct near jumps and direct near calls are relative to (E)IP.
Everything else requires proper relocation or must be rewritten to figure out the distance between "org" and the load location and use said distance in memory accesses.

Re: Relocation when binary get loaded.

Posted: Sun Feb 01, 2015 1:33 am
by HyperAssembler
I've figured out the problem.
The load address is specified in multiboot header, which is relocated by linker.

...I should probably slow down the steps to 64 bits.
I need to write a elf64 interpreter first.
OS dev is fun.

Re: Relocation when binary get loaded.

Posted: Sun Feb 01, 2015 1:33 am
by HyperAssembler
Thanks for your kind replies.