OSDev.org

Wow; nice work on the debugger guys... It's REALLY useful, it's much easier this way... Heh, although perhaps some work should be put into virtualization, I think Bochs would be a lot more popular if it had a real GUI (that means getting rid of the console altogether)...

Love4Boobies wrote:I think Bochs would be a lot more popular if it had a real GUI (that means getting rid of the console altogether)...

Prepare for this to be a bit controversial

A GUI would reduce the cross-platformness of Bochs without much increasing usability. Its much better that the Bochs team should be working on the emulation code.

Heh, although perhaps some work should be put into virtualization

? Bochs is designed from the ground up as an emulator - there are already plenty of VM's out there if that's what you want.

Cheers,
Adam

bewing wrote:After looking into it a little further (but not completely, yet) it looks like disasm works very well for me.
The only disasm function I use so far is bx_disassemble.disasm(). (I named my object bx_disassemble, obviously, like in the internal debugger).

The internal debugger sets arguments 3 and 4 to (bx_address)(-1), so I do that also. I would like you to tell me that it is always OK to do that. I do not want to ever set arguments 3 and 4.

It is a slightly sad thing if I have to instantiate an entire disassembler object, just to use one member function -- because it's a fairly big object. But it looks like that is necessary?

If you put a real values in arguments 3 and 4 - you will get more useful output from the disasm.
The arguments are CS:RIP of the instruction that you disassembly. If you supply these two arguments - you get absolute branch target printed after every branch instruction, i.e. instead of just

jnz .+0x000002

you get absolute linear target printed as well:

jnz .+0x000002 (0x132846478)

Stanislav

A GUI would reduce the cross-platformness of Bochs without much increasing usability. Its much better that the Bochs team should be working on the emulation code.

There are plenty of widget toolkits out there that are cross-platform.

? Bochs is designed from the ground up as an emulator - there are already plenty of VM's out there if that's what you want.

Virtualization and dynamic translation are on the TODO list.

@Stanislav: I see. Does it just add the "base" to the "ip" value, to make that calculation?
In order to load the instruction bytes from memory into the *instr buffer, I ALREADY had to do the full translation of the prev_rip/cs into a linear memory address. So I already have the current linear address available.
If I call disasm with the "base" set to 0, and the "ip" to the linear address that I already have, will that work?

Thanks for the info!

Love4Boobies wrote:I think Bochs would be a lot more popular if it had a real GUI (that means getting rid of the console altogether)...

That's exactly what I'm working on. I wouldn't be surprised if I had it posted by next week. There will be 2 versions of my frontend to bochs. One with a console (at least for now), and one without. The console (which connects the user to the "bochs internal debugger" via text) has included a LOT of (somewhat undocumented) features over the years that I do not want to try to duplicate in the pure GUI version. So if you want to use those features, you need to use WinNT's frontend, or the version of mine that has a console.

The pure GUI version should be a lot faster than the other -- perhaps even faster than the pure textmode version of bochs. The current console/internal debugger has a LOT of inefficiencies. Especially about how it handles breakpoints, watchpoints, and callbacks -- which need to be handled on every single instruction and simulated memory operation.

AJ wrote: A GUI would reduce the cross-platformness of Bochs without much increasing usability.

Well, I think I disagree. I'm halfway planning on being nice to jal, and porting my exact code to linux when I've got the windows version done. I've been writing the code with that in mind. So there should be no "cross-platformness" issues. I think the speed increase alone will probably make it worthwhile for some people. As I said, there are some features of the internal debugger that I would not duplicate, so there will be some theoretical loss of functionality.

But the main increase in usability should be for multi-CPU simulations.

It's much better that the Bochs team should be working on the emulation code.

Well, poor Stanislav *IS* "the bochs team". And if I were him, I'd be pretty tired of working on the emulation code by now.
... and in any case, I'd also say that the abilities of the emulator have at this point far exceeded the abilities of the current frontend to present the information. So, in fact, the effort at this point should be aimed at data presentation, for now.

As I said, there are some features of the internal debugger that I would not duplicate, so there will be some theoretical loss of functionality.

Why not?

@Stanislav: Can we expect all this to be merged to the trunk? If so, when can we expect the next release?

Love4Boobies wrote: Why not?

Because there are about 500 of them. All nearly useless, but not quite. I'm not going to create a special window, just to dump the detailed state of the emulated NE2000. Sorry.

And I think Stanislav is going to have to SEE my debugger, before he can decide.

bewing wrote:

Love4Boobies wrote: Why not?

Because there are about 500 of them. All nearly useless, but not quite. I'm not going to create a special window, just to dump the detailed state of the emulated NE2000. Sorry.

And I think Stanislav is going to have to SEE my debugger, before he can decide.

Agree

bewing wrote: Well, poor Stanislav *IS* "the bochs team". And if I were him, I'd be pretty tired of working on the emulation code by now.

Fair enough

OK, here's my last preliminary version (#2) of the Bochs GUI frontend that maintains the appearance of WindowsNT's official version. (My next version will have modified menus -- but I will post it on another thread.)

This version has these new features:
Parsing has been eliminated -- all data/registers/breakpoints/bochs information is pulled directly out of the bochs simulation.
This increased the speed noticeably.

Breakpoints toggle on a doubleclick.

The main windows are dockable and resizeable.

Compilation requires one more small change, besides the one required for version 1.
In dbg_main.cpp, there are the following 4 lines (line # 120 through 123):
static unsigned num_write_watchpoints = 0;
static unsigned num_read_watchpoints = 0;
static bx_phy_address write_watchpoint[MAX_WRITE_WATCHPOINTS];
static bx_phy_address read_watchpoint[MAX_READ_WATCHPOINTS];

You need to remove the "static" from the fronts of these 4 lines. After making this change, WindowsNT's version of stuff.h will still compile and run normally.

(The version 1 change was to remove the siminterface.h and textconfig.h #includes, and to add #include "bochs.h" in win32dialog.cpp)

Edit: PS @ WindowsNT -- while doing this, I noticed that (to the best I can tell anymore) your menu item for setting/clearing a Read Watchpoint will only do Write Watchpoints. And, of course, on the bigEndian/littleEndian dump submenu -- the 'A' is missing from the "Alt"s on each line.

EDIT2: removed obsolete download -- see this thread for the current download.

Why don't you both work on enhancing this debugger instead of having 2 separate ones?

WindowsNT is busy, and seems content with his. I'd bet he's not thrilled with what I've done to his nice code. And I'm almost content (and done) with mine, too. We still need to finalize the issue of the license. After that, it will be something for Stanislav, or other developers to play with. I need to get back to writing my assembler, and my OS, and other projects.

Fair enough

bewing wrote:WindowsNT is busy, and seems content with his. I'd bet he's not thrilled with what I've done to his nice code. And I'm almost content (and done) with mine, too. We still need to finalize the issue of the license. After that, it will be something for Stanislav, or other developers to play with. I need to get back to writing my assembler, and my OS, and other projects.

Do you have a patch for existsing Bochs files that I could apply and try to play with your code in Bochs ?

Thanks,
Stanislav

I'll be posting it for you either today or tomorrow, I promise.
I want to make a few changes to the menus, first. Just a tiny little time to wait, yet.