OSDev.org

Long-time reader, first-time poster.

I've been working on the bootloader portion of a hobby OS on and off for some time now. I just recently switched testing from VirtualBox to QEMU, and have finally started making some more progress, however a new issue has me stymied.

My entrypoint address (confirmed using my bootloader's PrintHex64 function, x86_64-elf-readelf, and hexdump) is 0x30081. However, the actual address is offset 0x81 into the .text section (when loaded, starts at address 0x300b0). As a hack, I changed the linkscript to compensate (and flogged myself for doing so), but I was wondering if I am either not supposed to load the program headers, or compensate for them by loading at a different address.

Regardless, I can now execute code in C, which I suspect will greatly accelerate development. Seeing that "Hello, ", even if it's not quite what I meant to print (I know what the problem is and have fixed it), was magical.

For my kernel I adjusted the entry address to compensate for elf header.
IMO this is acceptable as temporary solution since I have total control for my kernel, and linker script is just part of the code; and this greatly simplify the implementation of my boot loader. In long run if I have spare time and motivation I might support proper elf loading for my boot loader and relax this restriction.

However, I should point out that, when you implement application loader, this restriction become non practical and you should load program segment according to any sane value on the header fields.

I did some testing and found that changing the length of the string used as a parameter to the kprint call I have in kmain can cause the data section of the binary to suddenly align itself to the next doubleword boundary when it crosses a certain threshold, causing the data section to suddenly be 4 bytes off from where pointers in the text section expect it to be.

Rather than devising some new hack, I'll properly load the kernel (starting it out further up in memory, then copying down sections to their intended locations). The more I can do to get out of assembly, the faster this project will start moving.

Naturally, had I read the wiki entry on ELF more closely, I'd have learned that the headers specify to where each section should be loaded. Now I know.