Error loading uncompressed kernel without PVH ELF Note

[mephostophilez]

So I followed the Bare Bones tutorial (using nasm as the assembler). Using GNU make for building.
Everything builds fine, but when trying to run qemu with the built kernel binary, this happens:

Code: Select all

$ qemu-system-i386 -kernel bin/kernel.bin
C:\Program Files\qemu\qemu-system-i386.exe: Error loading uncompressed kernel without PVH ELF Note

I have very little to none experience with OS Development.
There's no results when searching this error message. Help would be much appreciated.

[glauxosdever]

Hi,


How are you building the kernel? Specifically, are you using a cross compiler? I'd assume your system compiler creates PE output (as you seem to be on Windows), and probably does other things that don't work for a freestanding executable.


Regards,
glauxosdever

[songziming]

`-kernel` requires bzImage or multiboot format kernel. Either make it ELF or provide your address fields of multiboot header.

Use `-f elf` to make NASM generate ELF format objects, and use ld to link them.

[mephostophilez]

How are you building the kernel? Specifically, are you using a cross compiler? I'd assume your system compiler creates PE output (as you seem to be on Windows), and probably does other things that don't work for a freestanding executable.

I'm using the precompiled i686-elf toolchain thing (https://github.com/lordmilko/i686-elf-tools). I don't know if that's ok, but it seems to run fine.

My Makefile:

Code: Select all

GCCPARAMS = -std=gnu99 -ffreestanding -O2 -Wall -Wextra
NASMPARAMS = -f elf32
LINKERPARAMS = -ffreestanding -O2 -nostdlib -lgcc

cobjects = $(patsubst src/%.c,objects/%.o,$(wildcard src/*.c))
asmobjects = $(patsubst src/%.asm,objects/%.o,$(wildcard src/*.asm))
objects = $(cobjects) $(asmobjects)

objects/%.o: src/%.c
	i686-elf/bin/i686-elf-gcc $(GCCPARAMS) -o $@ -c $<

objects/%.o: src/%.asm
	nasm $(NASMPARAMS) $< -o $@

bin/kernel.bin: src/linker.ld $(objects)
	i686-elf/bin/i686-elf-gcc -T $< -o $@ $(objects) $(LINKERPARAMS)

`-kernel` requires bzImage or multiboot format kernel. Either make it ELF or provide your address fields of multiboot header.

I'm confused. So it's either make it ELF or have the multiboot header? I have the multiboot header defined so it should be there.
I don't know what you mean by "provide address fields".

Use `-f elf` to make NASM generate ELF format objects, and use ld to link them.

I'm doing just that. I've originally had a typo in the nasm command, I was using `-felf32` (without the space) but it doesn't seem to behave any different now that I've changed it.

Should I use ld for linking though? The tutorial suggests using i686-elf-gcc.


Sorry if I'm missing some obvious points and thanks for understanding. I've thrown myself into OS development with little background.

[pistachio]

If you are building using a cross-compiler toolchain, ensure that you are using the same to link the format. I see you have a linker script, it'd be helpful to post that as well.

If you do have a valid multi boot header declared, you can either link it as a flat binary or as an ELF file. Use "i686-elf-ld" to link, and then make sure that nasm is using the correct ELF format.

[mephostophilez]

My linker script is just the tutorial code:

Code: Select all

ENTRY(_start)

SECTIONS
{
	. = 1M;

	.text BLOCK(4K) : ALIGN(4K)
	{
		*(.multiboot)
		*(.text)
	}

	.rodata BLOCK(4K) : ALIGN(4K)
	{
		*(.rodata)
	}

	.data BLOCK(4K) : ALIGN(4K)
	{
		*(.data)
	}

	.bss BLOCK(4K) : ALIGN(4K)
	{
		*(COMMON)
		*(.bss)
	}
}

[Octocontrabass]

Should I use ld for linking though? The tutorial suggests using i686-elf-gcc.

Some versions of GCC recommend using gcc to link instead of ld due to limitations in binutils. I can't think of any reason why you would ever need to use ld instead of gcc to link, so it's fine to keep doing what you're doing.

Based on the error message from QEMU, it sounds like your kernel doesn't have a working multiboot header. How did you define your multiboot header?

[theDude]

DISCLAIMER: I am dumb and may be missing the obvious.

This is not a multiboot entry issue.

This looks like an issue due to a somewhat recent change in the Qemu code base. From what I can tell in the source code, they are looking for a special PT_NOTE entry within the list of Program Header entries, I think...

They (Qemu) have glue code magic to generate the 32/64-bit elf decode functions, i.e., load_elf32(), which makes finding the source code quite difficult, but it's there.

https://github.com/qemu/qemu/blob/3e29d ... /elf_ops.h

I originally thought they were just looking for a general PT_NOTE Section with their magic value (0x12), but I think they are targeting the Program Header list of entries.

I'm not savvy enough to specify this new entry minimally through the link script/boot file(?).

This operation is apparently performed in the Linux source, but that ELFNOTE macro makes a fool of me.

[theDude]

If you are running QEMU on Windows, install the i386 emulator built before 2019. I used the Nov. 28 '18 build.

https://www.qemu.org/download/#windows

These versions don't include the new PVH/ABI changes and will run correctly with the '-kernel' flag with your ELF binary.

I don't know what is up with those newer Windows QEMU binaries. I was able to add the correct PT_NOTE entry in my kernel bin, with the correct entry address, but QEMU would fail to find the note about 25% of the time, and when it did, it looked liked the processor just kept resetting.

[devin122]

Just wanted to post an update here for people like me who find this thread trying to fix the issue. The broken PVH ELF Note handling can be bypassed by passing

Code: Select all

-machine type=pc-i440fx-3.1

on the commandline

[theDude]

Haven't checked the spec, but is there a flag to specify that this image shouldn't load unless the host understands all NOTES?