I suggest a successful compilation for the version 0.11.0-dev

[isoux]

I have created a new branch for the above mentioned version with necessary small changes, because I think it is useful for everyone to be able to successfully try this code for the latest version of ZIG.

[wilsncc]

Even if it's not merged, big thanks for doing that @isoux!

Interestingly, on my MacBook AIR M1 w/ macOS 13.4, qemu fails to run, giving:

➜  HellOS git:(0.11.0-dev) zig build-exe hellos.zig -target x86-freestanding -T linker.ld
➜  HellOS git:(0.11.0-dev) ✗ qemu-system-i386 -kernel hellos
qemu-system-i386: Error loading uncompressed kernel without PVH ELF Note

[isoux]

Thanks for the observation!

I just re-downloaded the zip file from my github, unzipped, compiled and ran with qemu ... everything works on my Linux.

I use: ZIG 0.11.0-dev.2160+49d37e2d1

zig build-exe hellos.zig -target x86-freestanding -T linker.ld
qemu-system-i386 -kernel hellos

[glyh]

I tried this, it's not working on my OS as well. I'm on Linux arch 6.3.9-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 21 Jun 2023 20:46:20 +0000 x86_64 GNU/Linux and zig 0.11.0-dev.3898+35a8e8a06

I modify the code a bit because @intToPtr is deprecated and replaced by @as and @ptrFromInt

error message I got is the same:

qemu-system-i386: Error loading uncompressed kernel without PVH ELF Note

[mypalmike]

Tried this with 0.11.0 with the ptrFromInt change. Compilation fails as below. Any ideas?

HellOS-0.11.0-dev$ zig build-exe hellos.zig -target x86-freestanding -T linker.ld
hellos.zig:22:5: error: runtime @call not allowed in naked function
    @call(.auto, kmain, .{});

edit/update:

I modified it to get rid of the .Naked modifier. I assume this will mess with the intended stack setup, but without digging deep into this, my hope was that it would just add some harmless setup and teardown cruft. Anyhow, I was able to build after that change. But then I get the same "qemu-system-i386: Error loading uncompressed kernel without PVH ELF Note" issue. I try running this:

$ grub-file --is-x86-multiboot hellos

This returns error 1. From what I've read, this tends to be explained by the multiboot header magic number not showing up in the first 8K of the binary. So I check using xxd, and "02b0 ad1b" (little-endian) shows up exactly at the first byte after 8K. So it seems like the linker script is putting .multiboot in the data section rather than the text section (edit: this was a mistaken conclusion - see update 3 below). Unfortunately, I'm not sure how to fix this.

edit/update 2:

Hacking away... I tried making a number of changes to the linker script. By reducing each section to ALIGN(1K), I got it so that it passed the grub-file test, with the multiboot header showing up within the first 8K. The kernel boots and displays the Hello Kernel World message. Obviously it's not ideal to have these two hacks (removing .Naked and reducing section alignment) but I was happy to get it working at all.

edit/update 3:

TL;DR: Change the linker script's .rodata section to have a trailing * after the rodata input specifier.

	.rodata : ALIGN(4K) {
		*(.rodata*)                      /* <----- Here */
	}

Longer story: running "objdump -h hellos" shows that that there are 2 rodata sections, named "rodata.cst8" and "rodata.str1.1". These do not match the linker script specification for rodata inputs, so the linker throws these into the output, disregarding our desired ordering. To fix, change the input specifier so that it matches these sections.