Another Alternate GUI for Bochs

nathanjphillips · Post by **nathanjphillips** » Thu Mar 19, 2009 9:12 am

ru2aqare wrote:
Combuster wrote:
nathanjphillips wrote:The inability to step over calls in the text debugger
Code: Select all
lb (current EIP + 5)
c
Or am I missing something?

No, no, that's fair enough, but when you're having to step through tens of lines or more of code a step over button is _really_ useful.

ru2aqare wrote: Recent Bochs versions even have a 'n' command (as for 'next') which steps over instructions like call, int etc. Don't even need to insert a breakpoint (which is good, since sometimes I miscalculate the address of the breakpoint...)

Dammit - why didn't I ask this question earlier? The version of the docs I was looking at didn't mention this, even though it's there in the binary I downloaded. Thank you, thank you, thank you!

Still interested in the GUI debugger though - let me know if there's any news.

N

stlw · Post by **stlw** » Thu Mar 19, 2009 10:16 am

Dammit - why didn't I ask this question earlier? The version of the docs I was looking at didn't mention this, even though it's there in the binary I downloaded. Thank you, thank you, thank you!

Still interested in the GUI debugger though - let me know if there's any news.

N

Probably it is good to start using "help" command in the debugger.
The "recent" versions of Bochs is probably starting from Bochs 1.4 or earlier. Every Bochs version I seen had this 'next' command available.

About GUI debugger - start using CVS version, Volker is too busy with getting USB device emulation working so no release in following two months planned.

Stanislav

bewing · Post by **bewing** » Fri Mar 20, 2009 12:37 pm

nathanjphillips wrote: Still interested in the GUI debugger though - let me know if there's any news.
N

Are you using Windoze or Linux? For Win, I can build you a binary, and email it (if your emailbox can handle a 2M file). PM me if you want it.

TNick · Post by **TNick** » Sun Mar 22, 2009 6:56 am

Congratulations! Great thing! I was trying something similar a while ago, but get stucked and forgot about it.

I have tested it on XP SP 2 with AMD Duron 1.6 GHz
Downloaded Bochs 2.3.7 source, added the changes as specified in install_instructions.txt (manually). The only fix that I had to do was to uncomment RefreshDebugDialog in win32_enh_dbg.h. Then make (in CygWin) worked.

Now, about the run test:

I can hardly tell which is the current line and where a breakpoint is set in asm window (maybe because of my LCD screen) I will try to look into your sources and change a bit.. at least for others that will have same problem
(E)IP and (E)SP registers sow 0 all the time (both in real and protected mode); since noone else reported this problem, it might be a local problem
bochs param_tree (or CTRL+F3, for that matter) will just clear the panel, without showing anything
on memory dumps other than 1 byte in lenght, if you try to resize a column you may discover other columns with meaningless content (workarround: place the pointer to left side of divider)
when pressing the continue button, I see that asm window is being refreshed. Maybe you could get rif of that to gain some speed.

In the [Features request] section:

SOURCE CODE!!! I am thinking about something simple: a index file for each source file to tell linear adress and offset in file.

Best regards,
Nick

stlw · Post by **stlw** » Sun Mar 22, 2009 9:27 am

TNick wrote:Congratulations! Great thing! I was trying something similar a while ago, but get stucked and forgot about it.

I have tested it on XP SP 2 with AMD Duron 1.6 GHz
Downloaded Bochs 2.3.7 source, added the changes as specified in install_instructions.txt (manually). The only fix that I had to do was to uncomment RefreshDebugDialog in win32_enh_dbg.h. Then make (in CygWin) worked.

Now, about the run test:

I can hardly tell which is the current line and where a breakpoint is set in asm window (maybe because of my LCD screen) I will try to look into your sources and change a bit.. at least for others that will have same problem

(E)IP and (E)SP registers sow 0 all the time (both in real and protected mode); since noone else reported this problem, it might be a local problem

bochs param_tree (or CTRL+F3, for that matter) will just clear the panel, without showing anything

on memory dumps other than 1 byte in lenght, if you try to resize a column you may discover other columns with meaningless content (workarround: place the pointer to left side of divider)

when pressing the continue button, I see that asm window is being refreshed. Maybe you could get rif of that to gain some speed.
In the [Features request] section:

SOURCE CODE!!! I am thinking about something simple: a index file for each source file to tell linear adress and offset in file.

Best regards,
Nick

Please don't invent a wheel

The stuff is fully integrated into Bochs sources tree. You just go to Bochs home page - Download Current - Download CVS Snapshot.
Unpack - compile -enjoy.

Stanislav

TNick · Post by **TNick** » Sun Mar 22, 2009 9:39 am

stlw wrote: Please don't invent a wheel
The stuff is fully integrated into Bochs sources tree. You just go to Bochs home page - Download Current - Download CVS Snapshot.
Unpack - compile -enjoy.
Stanislav

Oh, didn't think about this. I will give it a try. Thanks for heads-up, Stanislav.
But if I wait another hour and those features are not there, .... there are no words to discribe my anger

Nick

[Later edit]Yyyeeeeeessssssssssss! Now, that's what I'm talkin' about!!!!

Once again, thanks for pointing me to right direction, Stanislav!

stlw · Post by **stlw** » Sun Mar 22, 2009 11:01 am

[Later edit]Yyyeeeeeessssssssssss! Now, that's what I'm talkin' about!!!!
Once again, thanks for pointing me to right direction, Stanislav!

You still welcome to report any possible problems/bugs/issues to be fixed !

Stanislav

TNick · Post by **TNick** » Sun Mar 22, 2009 12:39 pm

Still, I see there's no way to make GUI debugger aware of loaded symbols. Am I missing something? If not, is this "feature" planned anytime soon?
Nick

nathanjphillips · Post by **nathanjphillips** » Sun Mar 22, 2009 5:25 pm

TNick wrote:Still, I see there's no way to make GUI debugger aware of loaded symbols. Am I missing something? If not, is this "feature" planned anytime soon?
Nick

What would be the best way to do it? From debug info or map files? In my OS I pre-process map files because I use bin format.

TNick · Post by **TNick** » Mon Mar 23, 2009 12:22 am

1.) If you are talking about the best way to generate the symbols...

The best way depends on what you use. I use fasm, wich has the ability (using some aditional tools which I had to modify a bit) to generate a symbols file in requested format.

While searching yesterday I came across this page.

2.) If you are asking about the best way to make GUI debugger aware of loaded symbols ... the rest of the words makes no sense,.... so I will assume 1.

Nick

[Later Edit]
For whoever needs a "P" button, these are the simple changest that needs to be added to CVS source:
wenhdbg_res.h [21] - insert

Code: Select all

#define CMD_STEPP   105

This will define a new ID (thanks for gaps)

enh_dbg.h [397] - change

Code: Select all

static const char* BTxt[7] = {

enh_dbg.h [400] - insert

Code: Select all

  "Step [p]",

enh_dbg.h [406] - change

Code: Select all

static int BtnLkup[7] = {

enh_dbg.h [407] - insert

Code: Select all

    CMD_CONT, CMD_STEP1, CMD_STEPP, CMD_STEPN, CMD_RFRSH, CMD_BREAK

You will end up with something like this:

Code: Select all

static const char* BTxt[7] = {
  "Continue [c]",
  "Step [s]",
  "Step [p]",
  "Step N [s ###]",
  "Refresh",
  "Break [^C]",
  "Break All"};

static int BtnLkup[7] = {
    CMD_CONT, CMD_STEP1, CMD_STEPP, CMD_STEPN, CMD_RFRSH, CMD_BREAK
};

win32_enh_dbg_osdep.cc [1397] - change

Code: Select all

  j = 6;

This is in B_WP callback, after
// create button rows
and just before
while (--j >= 0)

enh_dbg.cc [3136] - insert

Code: Select all

case CMD_STEPP: // step P
 doStepP();
break;

enh_dbg.cc [2566] - insert

Code: Select all

void doStepP(){
    // can't run sim until everything is ready
        if (AtBreak == FALSE || debug_cmd_ready != FALSE)
             return;
        
        AtBreak = FALSE;
        StatusChange = TRUE;    
        bx_dbg_step_over_command();    
        AtBreak = TRUE;    
        StatusChange = TRUE;    
        OnBreak();}

I would be gratefull if some guru would check this to enshure it is OK. All my tests in Windows tell that this is working without affecting anything.

Thanks.
Nick

stlw · Post by **stlw** » Mon Mar 23, 2009 9:32 am

For whoever needs a "P" button, these are the simple changest that needs to be added to CVS source:

Could you create a patch file for it ?
I will test and integrate the patch into Bochs CVS.

Stanislav

TNick · Post by **TNick** » Mon Mar 23, 2009 12:26 pm

Well, it looks like I wasn't carefull enough. Any command in View menu will cause Bochs to crash in ComCtl32. Sorry... didn't see that comming. I will investigate this and post any findings.

Nick

bewing · Post by **bewing** » Mon Mar 23, 2009 1:44 pm

Adding buttons is pretty complex -- especially since it should be done in both the GTK and Win versions of the code, for completeness. The F8 key does a "p". Or you can doubleclick to set a breakpoint. Not that I'm trying to discourage anyone from customizing their own code -- but programming/modifying a GUI is twice as hard as just adding some functionality to the non-GUI code.

TNick · Post by **TNick** » Mon Mar 23, 2009 2:00 pm

yeah, tell me about it ....

Well, the only shure thing is that each and every time when I access butons in View menu (except last one - Disassemble) it will crash. Olly shows that there is a call to CallWindowProcA:

Call stack of thread 00000748
Address Stack Procedure / arguments Called from Frame
02C0F980 7743931F COMCTL32.7740850E COMCTL32.7743931A 02C0F97C
02C0FB24 774399F0 COMCTL32.774392C8 COMCTL32.774399EB 02C0FB20
02C0FB40 7740A589 COMCTL32.774399A7 COMCTL32.7740A584 02C0FB3C
02C0FB8C 77D48709 Includes COMCTL32.7740A589 USER32.77D48706 02C0FB88
02C0FBB8 77D487EB ? USER32.77D486E1 USER32.77D487E6 02C0FBB4
02C0FC20 77D4C00E ? USER32.77D48734 USER32.77D4C009 02C0FC1C
02C0FC50 77D4E366 ? USER32.77D4BFBD USER32.77D4E361 02C0FC4C
02C0FC70 005454EC ? <JMP.&USER32.CallWindowProcA> BochsDbg.005454E7 02C0FC6C
02C0FC74 FFFF044B PrevProc = FFFF044B
02C0FC78 000704B4 hWnd = 000704B4 ('Break [^C]',clas
02C0FC7C 00001100 Message = MSG(1100)
02C0FC80 00000000 wParam = 0
02C0FC84 013B4F80 lParam = 13B4F80
02C0FCB0 00545718 ? BochsDbg.00545430 BochsDbg.00545713 02C0FCAC
02C0FCE0 0053C307 ? BochsDbg.00545610 BochsDbg.0053C302 02C0FCDC

I will look into it again tomorrow. I am shure that it has to be something with position or number of items (buttons, menues). I should also try to make one change at a time and build-run test...

Nick

TNick · Post by **TNick** » Tue Mar 24, 2009 8:26 am

Goood, it feels good!!!

Well, it looks like it works with few aditional mods:
win32_enh_dbg_osdep.cc 691

Code: Select all

SetWindowPos(hBTN[0],0,0,0,i,LstTop,SWP_SHOWWINDOW);
SetWindowPos(hBTN[1],0,i,0,i,LstTop,SWP_SHOWWINDOW);
SetWindowPos(hBTN[2],0,i*2,0,i,LstTop,SWP_SHOWWINDOW);
SetWindowPos(hBTN[3],0,i*3,0,i,LstTop,SWP_SHOWWINDOW);
SetWindowPos(hBTN[4],0,i*4,0,i,LstTop,SWP_SHOWWINDOW);
SetWindowPos(hBTN[5],0,i*5,0,WinSizeX - 5*i,LstTop,SWP_SHOWWINDOW);

This is for resize of buttons, in SetSizeIOS.

win32_enh_dbg_osdep.cc 1483

Code: Select all

 if (LW >= BTN_BASE && LW <= BTN_BASE + 5)    // convert button IDs to command IDs

wich is in WM_COMMAND case of B_WP. We change 4 to 5.

gtk_enh_dbg-osdep 153

Code: Select all

GtkWidget *CmdBtn[5];                   // "command" button row

We need to change 4 to 5. This was the shource of problems.

I hope I didn't forget any change. I will get back home soon and I will check it again.
Will atach a text file and a patch these days.
Also, I think it would be great if we could toogle ASM window between disassembly and source mode. As previously said, a simple (bynary? text?) file to serve as index will be the simplest way, I think.

Nick

OSDev.org

Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs

Re: Another Alternate GUI for Bochs