OSDev.org

@WindowsNT:

Also double check win32dialog.cpp win32_notify_callback, I think I 've changed it slightly ...

Yes, you added the line:

SendMessage(hDebugDialog, WM_USER, 0x1234, 2);

as line 4 of the case that you mentioned.


I think you should make your instructions a little more explicit in your readme, regarding commenting out the #ifdef. There are 4 or so #ifdefs of that type. I think it should say something like:

Find "#if BX_DEBUGGER" branch that contains RefreshDebugDialog() and InitDebugDialog() ...

I'm actually having a bit of trouble compiling stuff.h, but that's because I'm a nutcake. I'll get it figured out.

@Stanislav:

I tried to turn off the A20 stuff in bochs -- but there is a problem in cpu.cpp when doing that. The A20ADDR function is not defined, but on lines 660 and 663, the function is used with no #ifdef around it.

So. Anyone care to make a Linux port? :)


JAL

I don't think that the problem to make what I made was the Bochs internals. The problem was in the GUI, because linux people are not familiar with it. So I don't believe that a linux user intending to create a GUI would actually need my code, they need to be familiar with their own system native code - my "win32" code is practically useless for anyone wishing to port it to linux.

WindowsNT wrote:I don't believe that a linux user intending to create a GUI would actually need my code, they need to be familiar with their own system native code - my "win32" code is practically useless for anyone wishing to port it to linux.

Well, I haven't looked at the code yet, but KDE and Gnome programming is not that different from Windows, and I am pretty certain that your code is far from "practically useless".


JAL

I think yes it is way different, in my opinion it would be better to start from scratch and to simply borrow ideas from my debugger.

A more experienced Linux programmer might disagree with my opinion, of course, but talking about it theoretically is not very useful anyway; it must be proven in practice.

WindowsNT wrote:I think yes it is way different, in my opinion it would be better to start from scratch and to simply borrow ideas from my debugger.

Well, only if your code is crap(TM) starting from scratch may be good :). Ideally, of course, we'd use some abstraction layer, so changes would be done to both. Unfortunately, I have no time, so someone else must do it :).


JAL

This debugger gui seems to depend on the underlying bochs being built with the --with-win32 gui interface. Not only would the linux port need to replicate the event loop, dialog box, "Listview" controls (including color features), Windoze message handling, scrolling, & etc that are in stuff.h -- it would also need to replicate all of the win32 bochs gui interface. So I think WindowsNT is right -- that it would be best to start with the Linux gui interface and rebuild the debugger gui from scratch. I'm having enough trouble just trying to port it to Win98.

(... but I am sooooooo close to having it working. I have the window up and running, but it is not accepting input properly.)

Oh, and there seems to be a bug with the gui thinking I am still in Real mode, after I have most definitely switched to Pmode.

@JAL -- the code itself looks pretty good, and there are certainly some features -- the interface between this gui and the debugger -- that would be vital to port to a linux version. But of the 2700 lines in stuff.h, it looks to me like 1700 of them are Win-specific.

Actually more of them are windows - specific, because the issue was not to take the variables from bochs, but to arrange them in a good way.

There is a bug, the GUI checks the mode change *after* one instruction is executed, so if you are at a

mov cr0,eax

and execute it, the gui still thinks you are in r-mode. The p-mode will be visible to the gui after the next step.

Then I hereby want to file a bug report

I left it as is because it would be inefficient to re-query the state of all registers after a command is executed. The same occurs in long mode: The GUI switches to the "long mode" as soon as it sees the EFER long bit set, although the cpu is at compatibility mode at that time until paging is set and a jump to an 64-bit segment is made. I left it as is for simplicity of the code, knowing that you won't be much bothered

Actually, what is needed is to find a class-based communication to query the CPU state. Currently, my code parses bochs output, which means that the slightest change in the output format will render my code obsolete. I need a function that will return the entire cpu state in a big class; and then everything will be OK.

For example, return a CONTEXT (winnt.h) to describe the CPU state, and provide a way to query or set a memory location. Then everything will be much simpler and portable.

very nice program you have

one question. does the program accept debug commands stored in a file?

Not directly. However, it accepts any command that the text debugger accepts. And one of those commands is for spooling commands from a file, AFAIK.

@WinNt: Yes, I agree. It looks like you have the beginnings of that with your SIM-> etc. stuff. But parsing is good enough for now, and I am simplifying the parsing code. If Stanislav will create a nice interface into the CPU state (especially Mode, and register values), and a nice interface into the physical/linear memory models (allowing read & write) then this code will be simpler and nicer.

I think I'll have a modified version (with expanded features, and a bugfix) by this weekend. I have a lot of testing to do, to make sure I haven't broken anything -- and I do not currently have the ability to test Long Mode in bochs.

Make sure you pinpoint all the changes you have made so we are sure we are sharing a common version and I can put the auto update to it for all users.

See ... that's kind of a problem. I hate to tell you this, but I'm butchering your code. It was fairly easy to read, and functional enough, and I applaud you for the effort in building it from scratch.

But the vector based character parsing was inefficient -- I recoded it all in C, basically. The state machine was too simple -- debugger output was being lost. There were many unneeded windows messages being sent.
Your allocater was nice, but I've eliminated the need for it. I've changed half the lines in stuff.h so far.
You may very well not like, and not want to use my mods. Which is fine. Or you may want to rewrite my rewrite. Which is fine, too.