OSDev.org

stlw wrote:I just merged your debugger into Bochs CVS code. It compiles and works fine for me for now.
So any next enhancement or bug fix should be already a patch for Bochs CVS tree.
Do you like to have CVS write access to simplify things ?

I am glad that it is getting merged in. I do not think I will be making any "official" changes to this version for several months.

If you give me CVS write access, what I will be doing is adding the cpu number to all function calls in iodev -- preparing for multithreading in future versions. So that might be dangerous for you to do. (And adding the get_laddr() function into the siminterface somehow.)

I also suggest you would open another thread in the forum and ask others to start working with the debugger regularly and see their complains.
I would like to see peoples feedback and fix all major issues (if they are) before we issue official next Bochs release.

That is exactly what this thread was supposed to be. A formal test request for everyone to try the debugger and find errors. ATM, I doubt I would do better on another thread.

So you are welcome to download Bochs CVS sources and take a look. BTW, I changed the win32_enh_dbg.h to be .cc file, modified all the Makefiles and configure script, might be MSDEV workspaces should be modified as well.

OK.

Cheers,

Bruce

I am glad that it is getting merged in. I do not think I will be making any "official" changes to this version for several months.

If you give me CVS write access, what I will be doing is adding the cpu number to all function calls in iodev -- preparing for multithreading in future versions. So that might be dangerous for you to do. (And adding the get_laddr() function into the siminterface somehow.)

You must be crazy
All the functions in iodev cannot have cpu number because they have nothing to do with CPU, they are external devices connected to south bridge !
Even memory accesses from iodev have CPU parameter as NULL, if some device does memory access it is on its own, no CPU is responsible for this.

That is exactly what this thread was supposed to be. A formal test request for everyone to try the debugger and find errors. ATM, I doubt I would do better on another thread.

I have no idea if somebody still reads this, I am afraid we scared everybody with too technical thread ...
Anyway, if you have another way to publish this release - I will appreciate.

Stanislav

stlw wrote: You must be crazy
All the functions in iodev cannot have cpu number because they have nothing to do with CPU, they are external devices connected to south bridge !
Even memory accesses from iodev have CPU parameter as NULL, if some device does memory access it is on its own, no CPU is responsible for this.

Oh, but the CPUs are responsible! What happens if two CPUs access the same device on the southbridge at the same time? Are you trying to tell me that everything will work fine? Of course it won't. So all devices need to know which CPU is accessing them. If they detect conflicting CPUs they can print an error message, saying which two CPUs conflicted.
Also, in general, on a multiCPU system this will generate better error messages, if the devices can print the CPU number that caused any error. This is the only reason the CPU number is needed -- to detect multiCPU access errors.

And this will also allow all devices to be multithreaded in future versions -- because they will automatically "lock", while they are being accessed. It is absolutely necessary that there be some kind of lock on each "non-stateless" routine, for multithreading. And that is what the devices are -- non-stateless.

These changes don't need to all be made at one time. It would be much easeir to just get the CPU number passed in very soon -- because that would allow further testing later.

I have no idea if somebody still reads this, I am afraid we scared everybody with too technical thread ...

People are still downloading the patches that I posted at the beginning of the thread. The download count keeps increasing. -- But that is the only way I know that we haven't scared them ALL away.

###############
So, everyone! You heard Stanislav. He wants any debugging feedback that you can give on the current GUI debugger version (1.0) -- before it gets released with the next official version of Bochs! The patch is posted as post #1 (and #3) on this thread.

bewing wrote: So, everyone! You heard Stanislav. He wants any debugging feedback that you can give on the current GUI debugger version (1.0) -- before it gets released with the next official version of Bochs! The patch is posted as post #1 (and #3) on this thread.

Yeah, no thanks. Who makes an OS dependent GUI for an OS independent project, especially when there's a port of wxWidgets in-tree? Let me know once you get this thing working cross platform and maybe then I'll give it a try. I do most of my os-dev work on OSX and linux, and I've found that qemu + insight just works better, but honestly that's been mostly due to a lack of a decent GUI debugger for Bochs.

I suspect a lot of other people on here are unable to test this (or in my case, it is more of being unwilling to test) because it's win32 specific.

Oh, but the CPUs are responsible! What happens if two CPUs access the same device on the southbridge at the same time? Are you trying to tell me that everything will work fine? Of course it won't. So all devices need to know which CPU is accessing them. If they detect conflicting CPUs they can print an error message, saying which two CPUs conflicted.

The point is, normal systems don't even try to access the same device from different CPUs at the same time. That'd generally be bad design. And even if they do, CPU's fight for the frontside bus, and only one request gets patched through at a time in order for systems to stay synchronous (including wait states). Which essentially means that you should synchronize in the virtual FSB (i.e. in the calls that access memory or devices)

Passing the CPU on to devices is at best a test for horrible programmers and at worst a useless cycle eater. Not to mention its unrealistic. And as Stanislav mentioned, how are you going about dealing with DMA in any of its forms?
$.02


As for the debugger itself - haven't tried yet. I'm a keyboard freak so using a gui will most likely slow me down. And I use linux a few times too often.
$.04

What do you think bochs is, if not a testbench to weed out bad design? That is precisely why it should be in there.

And the FSB is not modeled AT ALL in bochs, so you have to synchronize somewhere, eh?

DMA is already handled asynchronously, so that is not a problem.

quok wrote: Who makes an OS dependent GUI for an OS independent project?

Good luck writing one in JavaScript. Every single GUI debugger frontend that I know about is OS dependent. So the answer to your question is obviously "everyone who actually tries to make a debugger GUI." Rather than just kibitzers.

Let me know once you get this thing working cross platform

Eventually. mystran has convinced me that it's going to be a pain in the @$$ to do.

bewing wrote:

quok wrote: Who makes an OS dependent GUI for an OS independent project?

Good luck writing one in JavaScript. Every single GUI debugger frontend that I know about is OS dependent. So the answer to your question is obviously "everyone who actually tries to make a debugger GUI." Rather than just kibitzers.

Perhaps you missed my point about wxWidgets being embedded in the bochs source tree. wxWidgets is just like GTK or Qt. It's a platform independent widget set for making GUI applications. And as for platform independent GUI debugger frontends, once again I'll suggest you take a look at insight. I've talked about insight in many threads, and I'm amazed nobody else as actually taken a look at it. It's built on top of Tk, and it's not so much a front end to GDB as it is entirely integrated with GDB. And *gasp*, there's even a windows port. Take a look: http://sources.redhat.com/insight/

bewing wrote:

quok wrote: Let me know once you get this thing working cross platform

Eventually. mystran has convinced me that it's going to be a pain in the @$$ to do.

mystran's comments about programming applications with the X tool kit aside, I don't see how making this cross platform in the first place (given a proper toolkit) would have been any more of a PITA than making it win32 specific. Oh, wait, it would require more testing. So what? You'd at least have a broader test base than you do now.

TreeViews and ListViews are not supported in wxWidgets.
Probably not superclassing or subclassing either. Dragging? Redirecting focus? Intercepting system "virtual keys"? Custom drawing functions for foregrounds and backgrounds? Hit testing?
So there goes 95% of the GUI frontend.

Attempting to work around those limitations is when we get into PITAland.

bewing wrote:TreeViews and ListViews are not supported in wxWidgets.
Probably not superclassing or subclassing either. Dragging? Redirecting focus? Intercepting system "virtual keys"? Custom drawing functions for foregrounds and backgrounds? Hit testing?
So there goes 95% of the GUI frontend.

Attempting to work around those limitations is when we get into PITAland.

Bah, that's all supported. Did you actually LOOK at what wxWidgets can do before posting any of that?

http://docs.wxwidgets.org/stable/wx_classesbycat.html

Try looking here:
http://wiki.wxwidgets.org/WxWidgets_For ... tion_Table

Especially under TreeView. "No support" it says.

Yes, I *did* look. And I still don't see a dang thing about subclassing, superclassing, or Hit testing --
and very little about focus redirection, mouse capture, or custom drawing. Knowing Win32 as I do, I also really doubt that the wxWidgets implementation of any of this is bug-free. I had to work around a major Win32 bug in the ListView controls as it was. So I think you are being very gullible about the cross-platform portability of this software.

bewing wrote:Try looking here:
http://wiki.wxwidgets.org/WxWidgets_For ... tion_Table

Especially under TreeView. "No support" it says.

Yes, I *did* look. And I still don't see a dang thing about subclassing, superclassing, or Hit testing --
and very little about focus redirection, mouse capture, or custom drawing. Knowing Win32 as I do, I also really doubt that the wxWidgets implementation of any of this is bug-free. I had to work around a major Win32 bug in the ListView controls as it was. So I think you are being very gullible about the cross-platform portability of this software.

Bewing, you've openly admitted to using Windows 98..

Perhaps it would be best if you quit while you're ahead...

Thanks..

Perhaps. But look, when you are talking about programming cross-platform, or for multiple versions of an OS -- success is measured by how well the code works on the hardest platform to program for -- the one with the fewest features and the most bugs. In the case of Windoze, the standard to measure by is '98. That is one reason why I use it. When I code for '98, and get the thing working perfectly -- I know quite well that it is going to work nicely on everything.

Consider how many people you make happy when you use a win32 frontend, and how many you make happy with a wx frontend.

Is it worth trading the win98 share in favor of all of linux + macos users?

Combuster wrote:Consider how many people you make happy when you use a win32 frontend, and how many you make happy with a wx frontend.
Is it worth trading the win98 share in favor of all of linux + macos users?

So the bewing's debugger frontend is perfect or nobody using it ?

Stanislav

stlw wrote:

Combuster wrote:Consider how many people you make happy when you use a win32 frontend, and how many you make happy with a wx frontend.
Is it worth trading the win98 share in favor of all of linux + macos users?

So the bewing's debugger frontend is perfect or nobody using it ?

Stanislav

While the concept of a nice GUI debugger frontend is great, my vote is on nobody is using it, because it's not available for our platforms.