OSDev.org

This is mine while I try to figure out why I'm getting a page fault when reading a memory mapped io device.

This happened when i tried to load a .COM without properly setting segments

Image decoder faults are a bit cliché, but since I've finally gotten around to working on a PNG decoder here's a WIP screenshot where things went a bit wrong:

SuperLeaf1995 wrote:This happened when i tried to load a .COM without properly setting segments

Reminds me of a friend's real-mode assembly-language unix. A program could be loaded wrong depending on its size, of all things. He suspected a bug in the FAT12 driver, but it was already an abandoned project by that point. It was only written to settle an argument, and my friend was too inexperienced to code assembler well.

Most kernel in this topic

I'm a little concerned about Bart's state of mind...

This isn't what is supposed to happen on loading a DOOM save

A classic

I've upgraded my build environment to the latest, and strange things started to appear...

With gcc, it doesn't matter if I compile for AArch64 or x86_64, with or without optimizations. Everything works (at this point all processes must block waiting for messages).
With CLang, everything works as expected for AArch64, but for x86_64 I get the following error. The interesting thing is, I don't even tried to mount root file system yet (FS task should just block too). Also, the backtrace looks pretty funky: "seterr" just sets a thread-local variable, it calls no function at all, definitely not "pipe_read", and there's no way that "mq_recv" called "main" either... Okay, there's no other solution, it's time for a through debug!

Cheers,
bzt

This is a neat looking kernel debugger

bzt wrote: Okay, there's no other solution, it's time for a through debug!

Quite an epic debugger you got there mate. Is it worth coding? Is it better than plain old Bochs?

@Monax, @jlxip: thanks!

jlxip wrote:Quite an epic debugger you got there mate. Is it worth coding? Is it better than plain old Bochs?

Well, I needed a debugger that I can run on real hardware using only minicom on the other side. I was thinking about implementing gdb-server, but that protocol is just too dumb for what I need. So for me it wasn't a question of worth it, but it was a necessity, a must have.

Otherwise writing a debugger is not a big deal. Here's a minimal one, only ca. 300 SLoC. It is for AArch64, but the code would be pretty much the same for x86 (except for the disassembler). This one is MIT licensed.

The code for the debugger you see on the screenshot is here. It's more complex, the common part being more than 1000 SLoC. The architecture specific parts are in their corresponding directories (supports x86_64 and AArch64). This is not a free software, licensed under CC-by-nc-sa.

As for the disassembler, it's available as a separate project, udisasm (for AArch64, I haven't migrated the x86 disassembler to this new format yet, but I'm going to. Any help would be appreciated ). The udisasm is licensed interestingly, the instruction tables and the generator script is licensed under GPL (so it's free, but copyleft), while the generated C headers are MIT licensed (so you can include the generated disassembler code in any project, even in proprietary ones).

Cheers,
bzt

So what should have been my page table ended up in the screen buffer.
If that's even what happen.

But given the repeating graphic pattern in the top of the screen, and that the setup of the page table is pretty much all that's happens in this test,
my guess is that my page table ended up in the screen buffer.

My all new panic screen:

Just testing NetDOS/32's page fault handler