Yes that would be a great feature to have, but I guess it makes accurate timing more difficult? I would love to have that in PCem for example 😁
The Bochs one is quite good, even if it is simple. I don't know any other emulators that have an integrated debugger, so I would be interested in hearing about them.

I guess for many purposes an adequate alternative is to use virtualization platforms and gdb (or whatever).
Do you have a specific goal in mind which would require this?

Mame has all that except the graphics viewer isn't available for pc drivers (it does exist and works for consoles and arcade drivers that use hardware tiles and sprites).

mr.cat wrote on 2021-03-08, 19:44:

Yes that would be a great feature to have, but I guess it makes accurate timing more difficult? I would love to have that in PCem for example 😁

PCem with a debug window would be really nice ... Unfortunately I have just basic knowledge about emulator coding, but as long as there is no recompiler a debugger shouldn't be a serious problem like lots of emulator projects prove .. I thought that would be the first thing to implement, since it helps to find emulation bugs ?!

mr.cat wrote on 2021-03-08, 19:44:

I guess for many purposes an adequate alternative is to use virtualization platforms and gdb (or whatever).
Do you have a specific goal in mind which would require this?

I've never used gdb ... just a little bit democoding in assembly for my i286 rig (http://www.pouet.net/groups.php?which=13038), so virtualizers and gdb seem to be a little too heavy for my purpose ..

crazyc wrote on 2021-03-09, 01:26:

Mame has all that except the graphics viewer isn't available for pc drivers (it does exist and works for consoles and arcade drivers that use hardware tiles and sprites).

thanks for the hint! .. didn't know that mame has cores for x86 emulation ("Arcarde") .. unfortunately I have no clue how to run dos programs, didn't find any howtos ... simply "mame myprogram.exe" doesn't work obviously 😀 .. I guess I'll need BIOS rom, Gfx Rom and a full dos image ?!

It seems UniPCemu also has some builtin debugging support:
https://bitbucket.org/superfury/unipcemu/wiki/Debugging

For 86Box there's this idea:
https://github.com/86Box/86Box/issues/799

Here's Sarah's take on the matter (from 2017):
https://pcem-emulator.co.uk/phpBB3/viewtopic.php?f=2&t=630

TheMechanist wrote on 2021-03-09, 10:30:

PCem with a debug window would be really nice ... Unfortunately I have just basic knowledge about emulator coding, but as long as there is no recompiler a debugger shouldn't be a serious problem like lots of emulator projects prove .. I thought that would be the first thing to implement, since it helps to find emulation bugs ?!

Yes that would seem logical.
However for bug hunting you can make do with just some simple printf() tracing, with not much extra code needed.
Or, maybe regular debuggers are sufficient for their purpose so there's little incentive to build their own, who knows.
I'm not an emu author, so this is all just idle speculation 😁

TheMechanist wrote on 2021-03-09, 10:30:

I've never used gdb ... just a little bit democoding in assembly for my i286 rig (http://www.pouet.net/groups.php?which=13038), so virtualizers and gdb seem to be a little too heavy for my purpose ..

Right, I can see that. Well gdb is the one mostly used on Linux (often with some sort of frontend), but there are literally dozens of alternatives.
The right tool for the job varies quite a lot depending on platforms involved, the end goal etc.
Some modern debuggers have support for reverse debugging and even deterministic replay is possible. Those can be very useful features, but they require some hardware support.

Hey, at least with Turbo Debugger you have the oldskool coolness factor 😜

TheMechanist wrote on 2021-03-09, 10:30:

I've never used gdb ... just a little bit democoding in assembly for my i286 rig (http://www.pouet.net/groups.php?which=13038), so virtualizers and gdb seem to be a little too heavy for my purpose ..

Oh nice - I enjoyed those prods. Thought there was something cool about Spectre Outside especially. 😀

TheMechanist wrote on 2021-03-09, 10:35:

didn't know that mame has cores for x86 emulation ("Arcarde") .. unfortunately I have no clue how to run dos programs, didn't find any howtos ... simply "mame myprogram.exe" doesn't work obviously 😀 .. I guess I'll need BIOS rom, Gfx Rom and a full dos image ?!

Yep, but you'd need that for PCem too.
I've never used the MAME debugger for PC stuff; may be a neat idea, but from my limited experience it didn't seem to be all that different from the DOSBox debugger.

Have you tried the one in DOSBox-X? it has a number of extra features/commands compared to the mainline DOSBox debugger, but you might have to dig to find them, because I don't think they were ever properly documented...

VileR wrote on 2021-03-09, 16:41:

Oh nice - I enjoyed those prods. Thought there was something cool about Spectre Outside especially. 😀

Thx! Hope I'll release something new soon ...

VileR wrote on 2021-03-09, 16:41:

Yep, but you'd need that for PCem too.

That's right, but much more user friendly 😀 ... mame requires a lot of special roms and they are hard to find ...

VileR wrote on 2021-03-09, 16:41:

I've never used the MAME debugger for PC stuff; may be a neat idea, but from my limited experience it didn't seem to be all that different from the DOSBox debugger.

managed to run 486@MAME (with "mame xyz" all machines are listed, that contain xyz, take e.g. at486 and it tells you, which roms are missing, then google is your friend) ... the debugging interface (mame machinexyz -debug -window) looks promising ... but it's harder to find the right entry point to start debugging (bochs uses a special op - E9) than with rom based consoles ...

the debug window allows mounting of floppy disks and disk images .. at least mounting my fdd images for pcem worked ... and the intro too 😀 ... memory viewer is nice, lots of "shortcuts" available, like VGA RAM ...

only for the sake of completeness - virtualbox has an integrated debugger too, it's command line driven .. invoke with "virtualboxvm --debug --startvm name"

So I guess for my purpose the oldskool way of using TD is for my projects the easiest way 😉

TheMechanist wrote on 2021-03-10, 18:10:

only for the sake of completeness - virtualbox has an integrated debugger too, it's command line driven .. invoke with "virtualboxvm --debug --startvm name"

Yes - that is one of those "virtualization platforms" I was talking about. Most of them have some form of debugging capability.
The line between an "emulator" and a "virtualization platform" is a bit hazy though. For example, the OSDev's list bundles them together under the emulators label.
I guess the difference between the two mostly comes down to offering hw acceleration or not, and the type of guest systems they support. There's probably not many cloud services running on PCem 😁

Nice choice of target platform btw, never had a 286 myself but those text mode tricks always warm my heart 😁

mr.cat wrote on 2021-03-10, 18:14:

Nice choice of target platform btw, never had a 286 myself but those text mode tricks always warm my heart 😁

"my" (fathers 😉 first PC was a 286, but my first computer was an Atari 800xl (but never really coded for that machine, but it's still my all time favorite) ... I'm getting old 😀

Here's a thought: In the 80s and 90s, there were some (very expensive) hardware debuggers such as Periscope IV.
Nowadays they've largely fallen out of favor, presumably because of the proliferation of hw virtualization support (well that is my uninformed impression on the situation).

How about emulating one of those? I've never used any of them so idk how interesting this could be - perhaps it's wouldn't be all that different from an emu-integrated debugger anyway.
Finding documentation (and software!) could also be bit of a problem...who has even seen one of these things in the wild?

But some emulators have POST cards, there is printer emulation and some freaking floppy disk sound emulation...
OK I realize these supernerdy debugging devices won't trigger quite the same level of sentimental response, as not as many ppl have used them.
But why not? 😁

mr.cat wrote on 2021-03-08, 19:44:

I guess for many purposes an adequate alternative is to use virtualization platforms and gdb (or whatever).

As you said later, the line between emulator and virtualisation is blurry. 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.

As 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). 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. The Bochs built-in debugger seemed better in this regard.

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. 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 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. 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.

doshea wrote on 2021-03-13, 10:17:

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've been wondering about that, being just a casual user of debuggers in general. It seems using gdbstub is the de facto standard for any project that needs a debugger,
but obviously there are some limits of what you can do with it. It just isn't very clear what those limits are in practice.

doshea wrote on 2021-03-13, 10:17:

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. 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 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. 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.

That's an interesting approach actually! There are many frontend contenders out there but most cater for gdb.

You can use `set architecture i8086` to tell GDB that the x86 CPU is in real-mode. The auto default could be buggy either due to gdbstub or bugs in GDB itself. The x86 16:16 real-mode is not very well supported and maintained in GDB overall. 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 frontend typically only deals with linear addressing for any debug operations such as breakpoints, memory and instruction disassembly. 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. Windows 32-bit binaries do not have any issues because the OS always uses base 0 flat segment with paging.

In essence, GDB is very good for legitimate software development when one compiles from source and possesses the full debug info and symbols. It isn't that great for reversing/hacking when one focus is on the disassembly and finding suspicious patterns in the memory, but can be made for such use cases when both the stub and frontend support additional capabilities to supplement the needs for reversing/hacking.

mr.cat wrote on 2021-03-13, 10:37:

That's an interesting approach actually! There are many frontend contenders out there but most cater for gdb.

I seem to remember finding quite a few frontends for Bochs's debugger too. I was planning to call mine BDG9000, subtitle "hopefully the 9001st Bochs Debugger GUI is the final one!" 😀

I'd like to think that one could make a frontend that could talk to various emulators (high up my list would be adding Qemu support) since really the basic operations like dumping memory and controlling execution are similar between all debuggers, they're just slightly different syntax and output formats. Of course I haven't even done much of the Bochs side 😀

An important part of course is letting the user run commands directly so that the GUI can have incomplete coverage of the debugger's features but still be usable.

kjliew wrote on 2021-03-13, 12:41:

The frontend typically only deals with linear addressing for any debug operations such as breakpoints, memory and instruction disassembly.

Do you mean gdb's own console-based frontend, or the various frontend GUIs you can get for it?

I seem to recall gdb has a thing called the "Machine Interface" or something which Emacs uses to talk to it, so that frontends don't need to deal with parsing human-readable output, which is nice. I suppose there is a chance the MI doesn't do everything the console-based interface does too, possibly the corner cases like handling real mode could have bugs in the MI which nobody has found because nobody uses it?

It isn't that great for reversing/hacking when one focus is on the disassembly and finding suspicious patterns in the memory, but can be made for such use cases when both the stub and frontend support additional capabilities to supplement the needs for reversing/hacking.

Thanks, it's good to hear from someone with more experience in this than me! I seem to remember gdb stubs can implement custom commands, I assume that's what you're talking about here? Do you know off the top of your head if any of the emulators we're talking about provide useful ones?

I found gdbstub in QEMU very useful. I had used it for x86 and ARM development. Bochs is also OK, but that's been a long time ago and I don't quite remember if I had been used to the gdb ways of debugging at that time.

mr.cat wrote on 2021-03-11, 19:22:

Here's a thought: In the 80s and 90s, there were some (very expensive) hardware debuggers such as Periscope IV.
Nowadays they've largely fallen out of favor, presumably because of the proliferation of hw virtualization support (well that is my uninformed impression on the situation).

How about emulating one of those? I've never used any of them so idk how interesting this could be - perhaps it's wouldn't be all that different from an emu-integrated debugger anyway.

I imagine that Periscope couldn't be as powerful as an emulator-integrated debugger because the emulator's debugger can see the state of more things on the system, whereas Periscope sees only the CPU. Of course using the CPU it can read data from other devices, but that's not the same as having direct access to the (emulated) internal registers. Whether that difference would really matter to anyone, I'm not sure.

Finding documentation (and software!) could also be bit of a problem...who has even seen one of these things in the wild?

These are good points.

I don't think too many people would have used them - you would have had to have been doing very low-level development to justify the expense. If say only 1% of the people who used them for work are interested in retro computing, that might round down to zero people!

But why not? 😁

It's a lot more work. To write an emulator you need to understand all the emulated hardware. To add a debugger you don't normally have to understand any extra hardware, but if you want to emulate Periscope you need to understand the interface between the ICE and the machine running the Periscope debugger. That's more work. Possibly their documentation doesn't explain that interface so you need to reverse-engineer it from their software, which would be a lot easier if you also had their hardware. But getting the hardware is probably going to be expensive. So there are a lot of reasons to not do the work which will only be overcome if an emulator author is really enthusiastic about this.

^ Yes, valid points. They are remnants of a bygone era...even if that was the state of the art then, nowadays we can achieve the same (and better!) results with software.
OTOH it could be interesting to hear some war stories from using these things. Maybe there could even be some techniques that have been lost in time and not incorporated in the modern tools, who knows (yeah unlikely I know 😀

With emulators the sentimental value cannot be ignored...
There is other now-obsolete machinery that falls into this same category and won't ever be resurrected in emulated form. Fax emulation anyone...? Naah better leave this alone 😁

kjliew wrote on 2021-03-13, 12:41:

You can use `set architecture i8086` to tell GDB that the x86 CPU is in real-mode. The auto default could be buggy either due to gdbstub or bugs in GDB itself. The x86 16:16 real-mode is not very well supported and maintained in GDB overall.

Uh, that could be a show stopper for me ... maybe this could help?

Special mode for GDB that allows to debug/disassemble REAL MODE x86 code

Will QEMU give a chance ... the frontends Nemiver & Insight look promising for my needs (simple "start & hack" approach) ..