OSDev.org

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

with these

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:

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

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.

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

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

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

Try something like this:

So it's some sort of nasm bug?


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

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


"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