In essence, GDB is very good for legitimate software development when one compiles from source and possesses the full debug info and symbols. Windows 32-bit binaries do not have any issues because the OS always uses base 0 flat segment with paging.
I knew I had to patch QEMU internal gdbstub to work with DJGPP debugging because the DJGPP pmode initialized non-zero base for code segment. The frontend typically only deals with linear addressing for any debug operations such as breakpoints, memory and instruction disassembly. It is designed to be portable across different architecture and x86 quirks such as segmented addressing, GDT/LDT/TSS stuffs are not very well managed and typically dependent on the stub implementation to deal with architecture specific details. The x86 16:16 real-mode is not very well supported and maintained in GDB overall. The auto default could be buggy either due to gdbstub or bugs in GDB itself. You can use `set architecture i8086` to tell GDB that the x86 CPU is in real-mode. I wrote it as a separate Python tool which interacts with the Bochs command-line debugger, rather than modify Bochs's built-in debugger GUI, because I wanted a nicer-looking Qt GUI and I wanted it to be easy for me and anyone else to hack in new things. I need to do a lot more work on it for it to be truly usable and I don't know if I'll ever get to that, but if anyone else is interested in this I might do some more work on it. It's just some hacks but it has the main thing I wanted, which is the ability to load a listing file output by Ida Pro and then highlight the line corresponding to the current CS:IP. I wanted a more powerful and user-friendly interface on the Bochs debugger and didn't like any of the ones I could find so started writing my own at one point. The Bochs built-in debugger seemed better in this regard. Unfortunately when I tried using Bochs + gdb + Emacs, it seemed that the gdb interface didn't have things exposed to it properly - I don't think it knew whether the machine was in real or protected mode, for example, or maybe it did know it was in real mode but still presented linear addresses.
I don't think anyone mentioned that both Bochs and Qemu have gdb stubs in them so you can use gdb to debug the virtual/emulated machine instead of the built-in Bochs and Qemu debuggers.Īs someone mentioned, there are some nicer interfaces that can sit on top of gdb, such as Emacs (some people might not consider that a nice interface but I do). I guess for many purposes an adequate alternative is to use virtualization platforms and gdb (or whatever).Īs you said later, the line between emulator and virtualisation is blurry.