>> Well, what I had in mind was this: we'll need to
>> have a general allocation mechanism for all plugins,
>> so they can allocate memory, I/O ports, interrupts,
>> etc. When a plugin (which could be the debugger)
>> allocates an interrupt, when the interrupt occurs
>> it is reflected into the user program to the plugin.
>
>Note that these are somewhat different things:
Yes, I am aware of that. However, the idea was that the
interface to the plugins should be consistant... the actual
implementation differs quite a bit.
>- A debugger will *intercept* a *software* interrupt (int 3),
> so that the monitor doesn't call the handler but returns to
> the user mode app. I don't see how a hardware model should
> need to do this. In fact, except for int3 / int1 I don't
> see why a general facility to redirect software interrupts
> would be needed ...
A debugger may want to intercept an arbitrary interrupt...
GDB cannot do this, but a specialised system-software debugger,
which will undoubtedly still be coded, can. I seem to remember
that that excellent DOS debugger, SoftICE, had this feature.
Moreover, another idea would be to reimplement an operating
system *outside* the VM, and only run the application code
inside it. For instance, one could hack up WINE to be a
plugin, which catches the windows system call from the VM.
This can have several interesting features; easier debugging
of new OS code, speed (don't have to bother virtualising ring0
code, because the ring0 code runs outside the VM ! Of course,
the cost is that a system call takes longer because we have
to switch back to the host context.)
-- Ramon
