Linker script confuses physical and virtual addresses

[restingwitchface]

In my continuing of implementing paging for my kernel, I've decided to load .text at 0xc0000000, .rodata at 0xc0040000, .data at 0xc0080000 and .bss at 0xc00c0000. I have the following section in my linker script:

Code: Select all

.multiboot.text : ALIGN(4K)
{
	*(.multiboot.text)
	_mbtext_end = .;
	ASSERT(_mbtext_end < 0x202000, "Paging setup code exceeds page boundary!");
}

. = 0xC0000000;
_kernel_base = .;

.text ALIGN(4K) : AT (_mbtext_end)
{
	*(.text)
	*(.text.*)
	_text_end_virt = .;
	_text_end = _text_end_virt - 0xC0000000 + _mbtext_end;
}
[...]

When I test the linker script, QEMU significantly lags my computer. When I pass the image through

Code: Select all

nm

, I notice _text_end is 0xc020514b, which means QEMU was probably trying to allocate 3 GiB memory. How can this be? The values of _text_end_virt and _mbtext_end are 0xc000412e and 0x0020101d, so _text_end should be 0x20514b. Does LD somehow not respect operator precedence when calculating values?

[Octocontrabass]

which means QEMU was probably trying to allocate 3 GiB memory.

QEMU uses the program headers to decide how to load your binary. Try "objdump -h" or "readelf -l" or "readelf -aW" to see the program headers.

Does LD somehow not respect operator precedence when calculating values?

You're running into something funky with relative symbols. I'm not sure exactly what, but moving the definition of _text_end outside the .text section turns it into an absolute symbol that has the value you're expecting:

Code: Select all

    _text_end_virt = .;
}
_text_end = _text_end_virt - 0xC0000000 + _mbtext_end;

It seems like this behavior is for backwards-compatibility. The manual tries to explain it here.