Wierd behavior of the linker

[Bonfra]

My second stage bootloader is composed of just one assembly file which I assemble with `nasm -f bin` to generate a flat binary with the code. I decided that I want to expand the code and add more files so now I want to generate an object file for each asm file and then link them together. Starting to convert the old process to this new one, I replaced this command

Code: Select all

nasm -f bin src/loader.asm -o bin/loader.bin

with these

Code: Select all

nasm -f elf64 -Wno-all src/loader.asm -o obj/loader.o
ld -nostdlib -o bin/loader.bin obj/loader.o --oformat=binary --entry=load -Ttext=0x7e00

So after adding the linking things I removed the org directive from the .asm file and added it to the ld as a flag together with the entry point.

The file outputted directly as binary is totally identical to the one with the linking stage except for a single instruction that has a major difference:
a near jump instruction in the 64-bit part of the code is totally different from the value it should be and obviously breaks everything.
dumping the binary I discovered that is exactly (0x130 + the org) bytes wrong so exactly these are the right bytes outputted from with the -f bin:

Code: Select all

e9 cc90 0f00

instead, these are the ones I get with the other method

Code: Select all

e9 fc0f 1000

The rest of the code is assembled perfectly.
It could be worth noting that there are no other jumps in the 64-bit part of the code other than the broken one.

I don't think the code is worth to be posted, but if it is necessary let me know and I'll create a branch in the git repo for this issue.

[Octocontrabass]

I don't think the code is worth to be posted,

I couldn't reproduce the issue. You'll have to post some code. (You don't have to post the whole thing if you can come up with a small example to demonstrate the problem.)

[Bonfra]

You'll have to post some code.

Code: Select all

;org 0x7e00
section .text
    global load

bits 64
load:
    jmp 0x00101000

I think that this is enough, it should be an absolute jump to that address

[Octocontrabass]

Huh! NASM appears to emit the correct code for later relocation, but then doesn't include a relocation entry.

Try something like this:

Code: Select all

jmp 0x00101000 + load - 0x7e00

[Bonfra]

Huh! NASM appears to emit the correct code for later relocation, but then doesn't include a relocation entry.

So it's some sort of nasm bug?

Try something like this:

Code: Select all

jmp 0x00101000 + load - 0x7e00

where load is? That 0x130 value? also from where does it come from?

[Octocontrabass]

So it's some sort of nasm bug?

Maybe. I'm not sure if ELF allows an anonymous relocation like that, it might only work when you have a symbolic name.

where load is? That 0x130 value? also from where does it come from?

"load" is the label you put at 0x7e00 at the beginning of the .text section. The 0x130 value comes from the address of the JMP instruction. If you look at the encoded operand (0x100ffc) it's just 4 less than the destination address; that's how JMP operands are usually encoded before relocations are applied.

[Bonfra]

"load" is the label you put at 0x7e00 at the beginning of the .text section. The 0x130 value comes from the address of the JMP instruction. If you look at the encoded operand (0x100ffc) it's just 4 less than the destination address; that's how JMP operands are usually encoded before relocations are applied.

Oh, yea I didn't connect the two things XD. Awesome it works thanks