Cooperative debugging: questions or answers?

[Artlav]

Greetings again.
This morning i was thinking about debugging in the OS, and then trying one idea out.

The idea is to port your kernel over to another OS, like windows, creating essentially a virtual environment for it to run in, but with more control than an emulator.
This allows you to debug both userspace and higher kernel functions from the comfort of an IDE and break-step debugger.

Here is the result in question:
http://orbides.1gb.ru/aprom-vm-100211.zip (last updated: post time+2:30)
The OS itself and it's slight description can be found here: http://forum.osdev.org/viewtopic.php?f=2&t=21536

Basically, it runs everything natively in a private memory space, intercepting interrupts and exceptions using NT's Vectored Exceptios and routing them into the unmodified kernel handlers. That way, most of the userspace runs unmodified, except for VESA and terminal drivers. Also, the device side is exposed, making it possible to mount host directories in the inner VFS, for example.

Now, the questions are:
Have anyone done something like that before?
Is it of any value to anyone here, specifically, me explaining how to set it up?
And, any ideas what to make of it?

[AJ]

Hi,

There is someone here doing this, but I forget who - sorry!

I believe this is a relatively common concept in Managed Language OSes, where the language runs via an AOT or JIT compiler. In effect, the kernel is a normal app and can be treated as such for debugging.

Anyway, it sounds like an interesting concept for a wiki article, so +1 here!

Cheers,
Adam

[~]

If it could intercept any specified event, mainly something like peripheral driver operations, and "log" the instructions and I/O and memory accesses, it could be valuable for trying to "reverse engineer" vendor-specific hardware and at least having a tool to make a driver native to any OS project with that information.

It could be highly valuable, and even more if it intercepted developer-specific I/O port and memory ranges and do something like "freeze" the driver in question to inspect step by step what those commands cause to the peripheral.

[Artlav]

If it could intercept any specified event ... ... inspect step by step what those commands cause to the peripheral.

Hm. Not sure if we are talking about the same thing. It is essentially my kernel ported to windows and running it's userspace, so it's only good for debugging the system one made, not any system. Think coLinux.

What you described is also an interesting idea - a see-thru emulator, that passes i/o to the host machine and back, running over bare hardware with debugger connected over thru a com port or something?