386+ CPU-only emulator?

[~]

I want to accomplish debugging directly on very small assembly code snippets, but I haven't figured how I could use Bochs debugger to provide a step by step analysis of results, not even using something like peter-bochs front end.

I need something like emu8086 but for 386 or better architecture.

And having to configure breakpoints every time I modify the program is too time consuming, just like trying to step through instructions, which is not a very precise process either when I just want to directly execute a few instructions instead of stepping any instructions that don't belong to my code, which could be thousands.

Does anybody know what program to use or how to accomplish it with the existing ones?

[thepowersgang]

I would use the bochs debugger with magic breakpoints. Nice and simple

(If the feature is enabled, bochs will break to the debugger when the instruction "xchg bx, bx" is encountered)

[bewing]

In some sense, it depends on what form these asm snippets are in, and what output you want from them. Do you just want to run them to a breakpoint and then examine registers and memory? Exactly how do you want to examine the registers and memory? Do you, instead, want to write the "results" back out to a floppy image? Do you want to control this process with a script/batch file? If it works "wrong", do you want to be able to singlestep through the snippet, and see what didn't work the way you expected? In some sense, you have two options for your initial format. Either you can build these snippets into floppy (or hard disk) images -- or you can build the snippets into a "fake" bios.

Depending on your choices above, bochs may be a good emulator to use -- or with some other choices, my "rebochs" may be a good choice.

[~]

The optimal I'm looking for is a program (no matter if emulated, but must be exact) in which I can specify the instructions directly, and have it "load" the program into memory and modify it accordingly throughout execution, and show changes in memory and in registers in each instruction step. And preferably, since it would have assembled the code, show its corresponding assembly source code line highlighted for dramatically improved readability of debugging, or interpret the assembly source code altogether as if it was a scripting language, if possible (or both interchangeably).

So if I enter this:

Code: Select all

org 0
mov ax,0
mov ds,ax
mov byte[0],'A'

Tell the debugger to load the program in the memory region that I specify and then allow me to step through every instruction with a "Step" button with a text area count of 1 instruction as default.

It would be just like a x86 code calculator, because there are tasks that preferably require such a lightweight debugging to make things easier. It looks to me that following any other procedure in such specific circumstances is like trying to debug blindly for the most part which should be solved.

By now, the best option seems to be the default "bochsdbg" program, and will look into the Bochs rewrite as I don't know what features it has exactly.

I have attached an HTML interface only of what I'm looking for or expect to accomplish (a lot of segment, general, control registers, etc., still aren't present but that's the idea), and as I said, I don't know if there exists such a program which would be like emu8086 but for 386+ or better.

[bewing]

AFAIK, there is no single program that does everything that you say, if I understand you correctly. You seem to want it to assemble as well as disassemble code? No such luck. You will need to go through an assembler to assemble your code. You have no choice about that.

It sounds to me as if you'd be best off hacking a few modifications into the bochs textmode debugger, to handle the loading of your assembled program into bochs memory at your designated location. The same could be done with the bochs or rebochs GUI debugger -- but hacking GUI code is more complicated. With either program, after you load your assembled code into memory, all you need to do is set CS and IP to your designated entrypoint, and you'd be running.

On the other hand, you can probably do this more easily.
Set up 2 emulated floppy drives. The first one is your boot drive. It has a bootsector that asks you where you want to load your assembled code to. Then it loads it off the 2nd drive, to that location. And runs it.
The 2nd drive simply points to a generic filename. Every time you assemble a snippet, you store the assembled file to that generic filename.

[~]

By the way, I forgot to attach the file, so here it is, if somebody is interested to see an actual HTML example of what I mean.

It seems that the case is that some programming will have to be done for such a program, and deal with Bochs tools meanwhile.

[rdos]

I have this as three different tools for my OS.

First, I built an emulator much like bochs many years ago that could handle startup-code in a fully emulated manner.

Next, as the OS has went past the initialization state (multitasking is started), there is a kernel-debugger that can be used to trace kernel & applications at assembly level. This is fully integrated with the OS, and as soon as a thread hits a breakpoint (int 3) or an exception, it will be available in the debugger. There is also a simple "panic" prior to multitasking that prints out the registers and locks up the system. (incidently, this is where Bochs ends-up when trying to run RDOS at the moment (some bug in Bochs) ).

Finally, there is OpenWatcom integration that makes it possible to debug applications at source-level with wd. I also plan to add kernel-level debugging to OpenWatcom at some point.

So, as I see it, there is not a single tool that handles this well. Bochs is mostly useful in the first stage were the startup-code and multitasking is debugged.

[charmeds]

Proposed is a computer and not CPU emulator. I know the topic is old, but give the CPU emulator only because if you and I need to test code that uses 32 bit registers EAX and so on thereabouts.

PS:
Turbo Debug know it is useful, but the code says there is slow and can not be loaded or saved the code you write.