OSDev.org

Octocontrabass wrote: ↑Thu Oct 10, 2024 8:58 pm

korangar wrote: ↑Thu Oct 10, 2024 8:41 amThe question is why the linker doesn't replace 0x0(%rip) with a constant (just like with the .elf), o replaces the MOV with LEA.

I wouldn't be surprised if those optimizations only work on ELF output. But why are you compiling position-independent code in the first place?

Hi

This code is a minimal extract from the kernel I'm playing with, that keeps the problem.
I completely understand I don't need PIC for this kernel, indeed, -fno-pic solves this problem (gcc -Q -v --help=common shows that -fPIC and -fPIE are enabled by default).

I think it's not an optimization: MOV 0xb(%rip), %rax does not store the address of the intended function, but the content of that address. It doesn't make any sense.

I know I'll die not being able to understand / know a 5% of what a linker does, but this looks like a bug to me... The linker resolves the reference to that function either by changing MOV to LEA and the offset to %rip, or by changing relative to absolute addressing. Which is ok. But keeping the MOV instruction with an offset of the %rip is not.

korangar wrote: ↑Thu Oct 10, 2024 11:22 pmI think it's not an optimization: MOV 0xb(%rip), %rax does not store the address of the intended function, but the content of that address. It doesn't make any sense.

The optimization is the combination of two things: replacing the MOV instruction with a LEA instruction, and changing the operand to point to the function itself instead of the function address in the global offset table. The linker needs to do both of those things for the optimization to work correctly.

It's probably a linker bug, but I don't think there's any reason to worry about it when you can disable position-independent code or link to ELF to get around it.

Oh, and you can add "-r" when you disassemble your object file to see information about symbols in the disassembled code.