OSDev.org

I like to figure stuff out on my own usually, but this is a simple issue that has me stumped. I am using a multiboot load sequence booting an elf module. Testing is done on both bochs through grub and "-kernel" through qemu. Multiboot header is setup as straightforward as possible, flags are 0x03, bytes 12-32 are 0(meaning it is definitely reading section info from elf file). When my assembly contains only 2 sections (code + bss), everything works great. I guess I have no way to confirm that it is recognizing the bss section correctly, but the code section is definitely loaded at the correct address and the appropriate entry point is called. The issue I am now having is by tying to add another section to be loaded.

readelf -S says:

[ 0] <no-name> PROGBITS 00100000 001000 001000 00 AX 0 0 0
[ 1] <no-name> PROGBITS 00101000 002000 00000c 00 A 0 0 0
[ 2] <no-name> NOBITS 00102000 00200c 00086c 00 WA 0 0 0

I can confirm through bochs and qemu that 0x101000 - 0x10100b does not contain the data from 0x2000-0x200b in the file. The file is exactly 0x200c in size. Am I missing something in the multiboot spec where it only supports a single elf section? Missing something from ELF spec? Do I have my header setup incorrectly? I am suspect of the linker, since that is what I am currently developing and testing! The headers look fine from everything I can tell. If it matters, this is on x86 in protected mode. If anyone has an idea of where I should be looking, it would be much appreciated, thanks!

The spec says that the header must be located in the first 8K of the binary. From your output, it will be placed 8K in which is too far.

Sorry, should have specified. The header is located in the first 32 bytes of the first section.

Just to clarify, it still boots fine with my previously posted sections. The first section loads completely to the appropriate location. The issue that I am having is that it does not appear to load the 2nd section at all (or at least it is not where I expect it to be)

"qemu -kernel" occasionally pops up with issues so you might want to try to boot using a real disk image and GRUB, and at least make sure you're up to date with VM releases and see if either of those make any differences.

Also, objdump gives a better section overview than your readelf does - for one I can't see if VMA/LMA addresses are different. I also can't see how your MB header is actually defined.

found out it was a linker error. The section was added as to section headers, but not program headers.

In the process I did find out that qemu "-kernel" does not fill in multiboot info at all