Hi,
Some time ago, I wrote a Gist [1] outlining what I believe to be the
ideal environment for debugging 16-bit code in real mode on Qemu. Based
on the feedback I've received, I decided to share it here to gather more
opinions.
It is commonly known that Qemu does not handle real/16-bit mode well with
GDB. To work around this, there are various hacks available, most of
which involve GDB scripts to make debugging less painful.
Basically, my idea involves two small and specific changes to the GDB
stub:
1) Returning the correct CPU mode as "i8086" or "i386" depending on the
current CPU mode (on x86_gdb_arch_name), instead of always returning
"i386".
2) Translating segmented memory to linear if in real mode, i.e.,
returning CS*0x10+EIP instead of just EIP, and similarly for ESP, etc.
Originally, I considered submitting a patch directly, but I wanted to get
your thoughts first. I understand that Bochs and similar tools have
sufficiently good debuggers, but it would be interesting if Qemu had some
improvements in this area.
I also acknowledge that my solution might not help in all scenarios, such
as CPU mode switches, so its effectiveness would be limited.
Ref:
[1]: https://gist.github.com/Theldus/4e1efc07ec13fb84fa10c2f3d054dccd
I might be interested in debugging some i8086 stuff for my Venix/86 emulation
project.
I'm curious, though. I see special cases just for EIP being returned as (CS << 4):EIP
and similar for ESP being just (SS << 4):SP. What does the debugger do, though,
for other cases where you need segment:offset addresses? Does it translate properly
behind the scenes in ways it doesn't do for ESP/EIP or do you have to examine those
addresses by hand as well? If I'm chasing a linked list with 16-bit addresses that assume
a particular DS, how does that work?
Warner