OSDev.org

Hi! Before all, the name of the thread is very little self-descriptive, since the problems isn't the FS or the HDD Driver, but started to appear with them. So most probably it isn't that.

First, the specs:
Bootloader: GRUB.
Compiler: NASM, GCC 4.6.1 & 4.4.3
Linker: LD
Deving OS: Linux Mint 12 64bit / Ubuntu 10.4 on Parallels on MacOS 10.6.8.
VMs: QEMU, Bochs and VirtualBox (in that order of preference and use).

Now, I'll tell you that, obviously, I'm developing an OS for x86. Multiprocesses, With an overall good Memory Manager, and a defficient FS by the moment. For the time being, it doesn't jump between user and kernel space. Is all done in kernel space (too lazy to activate the TSS) and handles poorly the exceptions (poorly as in "it reboots your PC" poorly). But is going quite well.

The problem araised when I added the disk driver to the equation. It just stopped working. It went to reset itself again and again at the moment of loading. I tracked the issue, and I got to the point that the problem was the IDT. It seems that every time I make the instruction int 80, it just reboots. Meaning that it cannot find the correct entry in the IDT. I'm deving this with a friend, that runs the MacOS. That machine is the one having the GCC 4.4.3. When we compile the OS there, it works! LIKE MAGIC (but with bits, instead of magic powder). So we continued developing a little further there. Then we stepped into the REAL problem. We just can't add more literal strings.

That means, we add: or we add And no matter what we do, how many characters it has, it reboots. It plainly stops.

But adding more code doesn't affect it at all.

In general terms, or compilation lines looks like this Now, we've been shuffling through some potential issues, those beings the next
* The size of the kernel is too damn high. We are messing with the IDT, and stuff, and we may just be breaking everything.
* Again, if it's not growing down, it's growing up. So It might be destroying the CR3, which is fixed at the 4M direction.

And the most unlikely ones:
* The GCC is working backwards. It just brakes our pure, pristine and flawless code.

And here is the question. Does anyone has the most remote clue about this? We've been banging our heads in the wall for a week now, And now idea the reason.

Beforehand, I'd like to thank you, whoever read this far, and is interested in helping.

Well, here's where you need to use a debugger at the machine level. Set a breakpoint just before where you think it is failing and then single-step through the code. Inspect the IDT; see if it is changing and, if so, work out where.

My guess would be a bad stack; that's one of the major causes of triple faults.

Thank you very much for the response iansjack. I was hoping no one would come with this answer. Is kinda the most troublesome solution around.

Any recommendation aside from the ones in the wiki for a debugger? I've been trying to use Bochs's, VBox's and gdb with QEMU, fruitlessly so far.

I like SimNow from AMD for this sort of thing. Runs on Windows or Linux, and it's free. Really easy to use.

You, kind sir, are doing God's Work. Thank you very mucho for the tips. I'll try SimNow now, and update if needed or any other problem comes by and my mind decides not to work.

fnmartinez wrote:The problem araised when I added the disk driver to the equation. It just stopped working. It went to reset itself again and again at the moment of loading.

Do you mean loading a driver dso? You may need to check your dso loader, the above code for const string use a different relocation type. From my pass experience I could run function within DSO but crash when adding global variable and it turn out I have bug for that specific relocation type.

bluemoon wrote:Do you mean loading a driver dso? You may need to check your dso loader, the above code for const string use a different relocation type. From my pass experience I could run function within DSO but crash when adding global variable and it turn out I have bug for that specific relocation type.

Sorry, I don't know what you mean by "a driver DSO". My OS is fairly monolithic. The drivers, so far, are kinda "hardwired" into the kernel. They're just functions I call. Is not like they're processes passing messages through the kernel. So no loading per se is needed. Is just calling the initializer function, and then setting the interface with the syscalls, and that's all.

Would you please elaborate more? I may be doing the same mistake and not even realizing about that. Sorry.

I see. I misunderstood it. By the way, DSO is dynamic shared object, it provide a way for plugin extensions. In unix world it's .so and on windows it's .dll.

Now I read more of your description on the issue. Since you and your friend has different outcome using different OS/gcc, it's probably a good time to try to build a cross compiler to isolate issues which may arise from platform/host dependent parameters.

We are already cross compiling with GCC. As you can see, even though we both have x86-64 platforms, we develop for x386 processor. That's why we are testing in Bochs with x386-only flag. Since the OS is in a very early state, sticking with the basics, and using the most bare components seemed the best way to start. Or so we thought...

No, your not unless you add -ffreestanding to your gcc flag or GCC_Cross-Compiler.

Oh... I see now. Thank you then. I'll check up on that. I don't know if it will solve our problem, but it will certainly save us future headaches.