What should I put in a panic screen(to be usefull for debug)

[BlueShell]

I made a panic screen with a simple output to warn about a kernel error, but I think I should add to it some things to make it more useful when debugging, but the problem is... What should I add?
I mean, what do you think is useful to know when a kernel crashes? How can I implement that things? Thanks in advance!

[iansjack]

Contents of general purpose, segment, stack pointer, flag and IP registers at a minimum. (Note that you want the values before any exception handlers were called.)

You could also put in details of GDT and IDT. Have a look at the information screen on the qemu monitor for some ideas.

[isaacwoods]

If you want to put a little more effort in, you could provide a stacktrace (working back through the stack frame return addresses) or even provide a disassembly of the instruction that caused the panic (if for example caused by a page fault)

[mallard]

You're asking what information would be useful for debugging your OS/applications? It's your OS, you're the one debugging, you tell us...

Personally, I don't put much information on the "panic screen", just a basic description of the error and the process/thread IDs involved, since that's "user facing". The rest of the information (register values, an attempt at a stack trace, etc.) is dumped out to the serial port (this will be configurable eventually).

If you find yourself needing information that's not available, you can always add it. Code isn't immutable.

[Korona]

In my experience looking at any register over than RIP and CR2 (and maybe RSP) is a waste of time once you get past the "there might be an error in my paging/GDT code" stage.

Printing the program that caused the panic is essential. Maybe also print the context: Did the panic occur during an IRQ handler? In a page fault handler? In a syscall?

Stack traces are certainly nice if you have them but also quite complicated to implement: You have to write a DWARF unwinder and ensure that all assembly functions are correctly annotated with CFI pseudo instructions; this will be a PITA.

[iansjack]

I have found it very valuable to see that a register I expected to contain a valid memory address is zero (just a simple example).

[azblue]

In my experience looking at any register over than RIP and CR2 (and maybe RSP) is a waste of time once you get past the "there might be an error in my paging/GDT code" stage.

Printing the program that caused the panic is essential. Maybe also print the context: Did the panic occur during an IRQ handler? In a page fault handler? In a syscall?

Stack traces are certainly nice if you have them but also quite complicated to implement: You have to write a DWARF unwinder and ensure that all assembly functions are correctly annotated with CFI pseudo instructions; this will be a PITA.

For "normal" functions, won't RBP point to the old RBP, followed by (going up) the old RIP, followed by the passed variables? Couldn't you get each function's stack frame by following the trail of RBP's?

[Korona]

That only true if you compile with -fno-omit-frame-pointer. In addition to that you still need some annotations to mark IRQ/exception entries, otherwise your backtrace will not work across those frames.

I have found it very valuable to see that a register I expected to contain a valid memory address is zero (just a simple example).

Yes, if you're coding in assembly, that will be helpful. If you're coding in a higher language you first have to figure (from the disassembly) out which register stores which value; this process is often tiresome and not effective. Instead I usually resort to printf() debugging to check if any variable contains bogus values. This is usually even faster than invoking GDB and setting the correct breakpoints.