GUI Debugger Discovery

[Octacone]

I just wanted to share something really really interesting. I found out that Bochs has this really helpful GUI debugger. It can dump GDT, IDT, stack, page table, memory addresses. Very useful tool for somebody who knows how to use it. It is much simpler to use this GUI debugger than any other textual one.

Here is an example of what it can be used for:
GDT debugging:
[Picture 1: GDT loaded by GRUB]

[Picture 2: a custom proper GDT]


How to activate it:
Open your Bochs configuration file and paste this:

Code: Select all

display_library: sdl, options=gui_debug
magic_break: enabled=1

By doing this you will automatically get this screen every time you run your OS In Bochs. Also by enabling so called magic break your OS will automatically stop and let you debug. You need to do

Code: Select all

xchg bx, bx

in order to insert a breakpoint. (Assembly file)

i created this topic to show how amazed I was when I discovered it. This will make me stop hating debugging so much.

[matt11235]

This will make me stop hating debugging so much

You could have used gdb --tui with QEMU or something else too, it makes it a lot easier to use.

Also you didn't do a very good job of blurring out your code in the images, my eyesight is very poor and I can still make out most of the text

[Love4Boobies]

The Bochs GUI debugger was originally contributed by one of our members, bewing. Him and Stanislav (one of the two maintainers of Bochs and also a member of the forum) got into a disagreement so bewing stopped contributing and started working on his own emulator, ReBochs, which was supposed to be a faster Bochs with a less messy implementation. As far as I know, he is still working on it but development is rather slow so it's not a suitable replacement.

[iansjack]

You could have used gdb --tui with QEMU or something else too, it makes it a lot easier to use.

gdb has the distinct advantage that you can debug at C source-code level as well as assembler level. And it has a very rich set of commands; a little difficult to get to grips with and learn, but well worth the effort.

[matt11235]

You could have used gdb --tui with QEMU or something else too, it makes it a lot easier to use.

gdb has the distinct advantage that you can debug at C source-code level as well as assembler level. And it has a very rich set of commands; a little difficult to get to grips with and learn, but well worth the effort.

The learning curve isn't too bad, there are only a few commands to learn and it's well worth the time.

[Love4Boobies]

I don't know why you're bringing GDB up. The OP specifically mentioned what the Bochs debugger is useful for---things that GDB can't do.

[iansjack]

I didn't see anything mentioned that gdb can't handle.

Anyway, what's your problem with additional, related information?

[Love4Boobies]

GDB doesn't know anything about CPU data structres such as descriptor tables, page tables, etc. The TUI version of GDB was mentioned as an alternative but it's really meant to solve a different problem.

[Solar]

GDB doesn't know anything about CPU data structres such as descriptor tables, page tables, etc.

If GDB runs in ring 0, like it does for DJGPP, it can display those structures. If GDB doesn't run in ring 0, you'd have to provide a syscall for reading those data structures -- which GDB in turn could use.

[iansjack]

Let's not forget that qemu has it's own monitor. A combination of this with gdb is a very powerful tool.

[Love4Boobies]

Interesting, I didn't know that. However, it still can't handle things like interrupts and other low-level things (some CPU-related, some not) even if it can display those structures.

There is no need to make a case about GDB being useful for systems debugging, I readily acknowledge that. You don't even need QEMU's monitor for it to be useful. In fact, I think it's way more useful than the Bochs debugger but the latter is useful for a different set of problems, still.

[Sik]

Or for that matter, act like one should stick to a single debugging tool and nothing else (which is how things seem to be worded here). I lost track of how many times gdb turned out to be utter trash for debugging my problems, and sometimes I resort to multiple tools to see what's going on.

[iansjack]

Most of the posts here seem to be suggesting multiple tools rather than just the built-in Boch's debugger. Makes sense to me.

[Love4Boobies]

Maybe I should have gone the extra mile do explain that's my opinion as well from the beginning.