OSDev.org

I've got as far as integrating a malloc() into my C code, integrating the keyboard, detecting hardware, and I'm working on a command line interface (slowly but surely, because I'd like to get every little detail down).

Anyway, onto the subject of the topic: My panic() sucks.

The reality is, all it can do is tell the user that a kernel panic has occurred for whatever reason, and halting the system. While some may say that would suffice, what happens when I get a page fault and I don't know where the error came from?

I'd like to do a memory dump function. dump() or simply integrate it into panic() (although a separate dump() function would probably be better).

What I've tried (some of these, if not all of these, are probably stupid of me )...

-looping through memory addresses from 0x000000 to 0xffffff using a for() loop, and then puts(&address); This dumped random characters on-screen (although they were in alphabetical order, which is probably something worth noting).
-early on when I didn't know sh** about kernel development (trust me on this one, I didn't), I attempted to simply test whether or not I could memset without a crash. If it did, it would not panic, but instead attempt dump the results on screen. That probably didn't even come close to what I was looking for.

In general, I'm not exactly sure what I need to do to dump physical memory. That's physical memory.

I know the logic behind the code, but I don't know the code. Can someone fill me in on this or show me what needs to be going on?

So in other words, it's not about dumping memory, but it's more about a stack trace of the error?

If you add some stack tracer to your panic function you'll know better in which function actually happened the error.

To dump errors you may dump memory with and without paging enabled.

Also, puts(&address) wont work, if a byte is zero (I asume your puts prints up to string strlen) it would stop. Better loop on each byte and putch.

Cheers,
Gonzalo

Hi,

DrLink wrote:So in other words, it's not about dumping memory, but it's more about a stack trace of the error?

It's about providing as much useful debugging information as you can (to make debugging easier), without risking crashing the OS completely.

The first part isn't that hard - for each exception think about what causes it and display information to help you debug the cause. For example, for a page fault handler you'd want to display CR2 but you probably won't need to display SSE registers, and for a SIMD Floating Point Exception you'd probably want to display SSE registers but won't want CR2.

The second part is the hard part (not risking crashing the OS completely). For example, if the video driver crashed then you might want to send debugging information to a file on disk instead asking the video driver to display the information on the screen (or instead of asking the video driver to switch to default video mode so that the kernel can display the information on the screen itself). Of course if the kernel crashes you might not be able to rely on anything working - in this case the best course of action might be to do nothing ("jmp $"), so that you can find the problem in an emulator without worrying about figuring out what the panic function may have trashed.


Cheers,

Brendan