OSDev.org

http://code.google.com/p/peter-bochs/wi ... chDebugger

If you want some new debugging command, please post it into the comment. Thanks!!!
http://code.google.com/p/peter-bochs/wiki/feature

thanks
from Peter ([email protected])

Funny name.. bochs is pronounced "box", so.. "peter-box" sounds rather inappropriate.. like out of an 80's porno movie.

Surprise!

Umm, it's bochs, with two minor additions? That's it? Couldn't these have been added to the main bochs trunk (ala feature requests) rather than creating a new distro?

Hi
I am adding other functions. I tried to submit the patch to bochs team, but they said it is unuable
thanks

If you read between the lines, the abridged version of Stanislav's reply would rather read: "learn to make proper patches".

It's bad courtesy to blame the bochs team for your errors. The bottom line of his observation is also, that your version is going to be impossible to maintain when bochs is releasing new versions. And I rather have bugs fixed, than to have some new feature I can do without.

I will try to submit it again later. Please don't think I blame them

It's nearly always better to try to get the maintainers of a package to accept a patch than to fork the project. With a fork, either you'll attract away some of the original project's user/developer base, and hence lead to unuseful duplication of effort, or you won't, in which case why bother?

yes, that's why I will submit my patch again

The GUI looks neat in any case. I'm guessing it's written in Java since I see Eclipse open and a little JRE icon flashing in the titlebar?

Is there any way it's possible to not only show the values of registers, but also of any variables that might be active? I know it's possible for applications, but I'm not sure if it's possible for operating systems too (I'm guessing yes, since they're just another form of an executable). I'm also not sure how much work that'd involve and if it'd be worthwhile. It would give the name of the variable and its current value in a list, just like it lists the assembly registers.

berkus wrote:Looks neato, does it really work? I couldn't for my life make the now-integrated graphical front end work. With wx gfx backend it starts up, but is awfully slow and hangs every once in each run.

Look on VirtualBox. They do exactly non-integrated graphical front end in Java.

Stanislav

Dear Mr Creature
I am making this feature, when the register value is changed, highlight it with some color.

Everybody, please check this out http://code.google.com/p/peter-bochs/wi ... uggerSetup , any feed back or bug, please report to here http://groups.google.com/group/peter-bochs

I think it would be better to propose the Bochs team a simple and very configurable "Plugin Interface" where plugins can be installed by copying them in a directory and then being able to point to more than one plugin directory using an INI file for Bochs itself (and maybe custom BXRC files with "plugin" directives --- to not break your old BXRC files).

In this way, it would be far more probable that they officially support your changes, but in the primary form of a plugin interface. Then you could offer the interface you are showing now for shipping with Bochs in the default Plugins directory, as a plugin, or as a separate but near download at least.

Then I have some requests:

- That you can temporarily halt at runtime with the only action of reading or writing, when you write or read at specific I/O ports, processor registers (ANY of them) memory locations by writing a specific value to them that Bochs should watch for THAT SHOULD BE SPECIFIED BEFOREHAND (in a BXRC?), or maybe other ways you can think of. In this way, it would provide the possibility of using any normal ports (instead of a "Bochs debug port") and standard resources that would have no effect at all when run in a real machine.

- You could also specify different actions for different values (both specified by the developer) to a "debug variable" (maybe even small language-like script directives for this purpose?)

- That you can have an interface with all existing I/O ports, which shows whether they are read-only, write-only or read/write, and show its hex values and maybe a technical description of the register width (byte, word, dword, qword...) and its "standard" bit-field definitions (in case those ports were moved by the code running and don't belong anymore to the standard device location).

- That there's a memory dump at all times, that you can also modify when you halt temporally, etc., and with different views (disassembly interpreted as 16, 32 or 64, memory addresses shown, a column of hex values at the left and the ASCII characters at the right in rows of 16 characters, etc, just like HIEW program).

- A way to show how many CPU cycles an instruction, memory or I/O port access takes, or how much time a device delays for making bit-field or state changes (but I think this one maybe would not be very precise when emulated anyway, and that is unless such delays get investigated on real hardware and emulated as part of this Plugin, and with the possibility to configure in a range that makes sense according to the differences that there could exist on real hardware, IT WOULD BE VERY USEFUL TO EMULATE THE BEHAVIOR OF DIFFERENT MACHINES WITH THE SAME BOCHS).

- This maybe would be part of another plugin, but it would be good also to emulate different PCI devices for "testing" different virtual video, sound, network or other cards.

- I think that also a feature to fill empty RAM with random trash would be appreciated to override the zero-fill memory of Bochs and thus really see if a program still works correctly with a random memory environment in case of forgetting to initialize stuff and having the luck to have it in a zero-filled place.

Dear Berkus, correcting this stupid issue, thanks

Dear ~, thanks for your idea.

second release