My OS Kernel in D: Some embedded strings don't work

I'm aware that is a rather difficult question to answer, mainly because there's so many things that could be wrong that it's hard to pin things down. But I'll give as much info as I can; hopefully that'll help.

I started writing my own kernel using the D language and the Digital Mars D compiler, and after a lot of trouble with figuring out how to generate flat binaries that can be relocated, I finally came up with the idea of generating an ordinary PE file for the address 0xC0000000, and replacing all of its headers with the byte 0x90 (the NOP opcode). This worked perfectly fine, and I was able to write things o开发者_如何学Pythonn the screen, set up paging, enter protected mode, etc. perfectly well, with--of course--the help of a 16-bit assembly-based boot loader.

Everything was well, that is, I decided to port the D run-time library for use in my kernel. I managed to extract a subset of the library and modify it to get it to compile into my app. Then I ran my program. (Note: I did not use the library at all; my code was the first code executing after the boot--the first thing that happened was printing "Kernel" to the screen, and no run-time code was called before that.)

A D array (and hence a string, since a string is just a char[]) is no more than a structure with a pointer and a size member, so on a 32-bit system it would be 8 bytes big. The funny thing was, when I ran my program, the structure's members showed up to be zero -- that is, both the pointer and the size were zero. (I verified this by printing the pointer's value to the screen, as well as the length member -- both were zero.) As soon as I removed the source code for the run-time (which was never executed anyway), they worked fine.

I narrowed this down to two possibilities:

1. The stack was somehow not set up correctly: I ruled this out, because everything worked fine without the runtime library, and I confirmed that no other code was executed before my code by disassembling the file.

2. Something is funny with the PE file sections: I checked, and figured out that there were two TLS (thread-local) variables in the version with the run-time. Sure enough, when I made them shared (rather than thread-local), my code worked! However, my code still exhibited the same problem when I called code I'd written in a different file--only kernel.d, which is the startup file, behaved correctly with strings; in the other files, the arrays were zero again.

Now, does anyone have any guess as to why this might be happening?

If any more information is needed, I'll be happy to post it.

Thank you!

First, a disclaimer: I don't know the first thing about D.

Second, another disclaimer: Based on the use of the term "PE file" I'm going to guess you're using Windows. I'm about to give a suggestion for a GNU toolchain...

But... Assuming the D compiler generates object files just like any other... Why not do the following (this is what I did when I worked on a hobby OS in C, back when I had time for such things):

• Generate an ELF binary for your kernel... To do this, build all your object files as normal. At the link step, feed a linker script to ld that will define things like start address, the order of sections (text, data, rodata, etc.) of the binary...
• Boot it with GRUB (Fairly easy to do... You need to put some magic words near the start of your binary. You can do this with db or dw type statements in an .asm file, provided the corresponding obj ends up linked near the beginning of the kernel. Check out this link)

This way you can focus on more interesting things than hacking up a PE header or writing a bootloader.

Of course... It sounds entirely possible that there's some problem in the code itself, rather than the way you link. It might be informative to run it in something that will let you step through the assembly output. The x86 PC emulator qemu has some debugging options which will output assembly and register state to a log. I used to use that.

One year later...

Solved! :D

(> '.')>   (^'.'^)   <( '.' )>   (v'.'v)   <('.' <)

It was a problem with my boot loader: I was reading too few sectors into memory. (Namely, 64 sectors instead of 128 125.)