Ramon van Handel <[EMAIL PROTECTED]> wrote:
> What's the problem ? They both set TF, so it'll first trap
> to the ICE and then to the guest debugger. Only need to
> watch out the the interrupt is relayed on correctly.
Indeed, the guest debugger should receive interrupts only if
it is expecting it. Furthermore, if the guest looks at the TF,
it should see it set only if it set it itself ... (All this is
not so critical at the moment, but it can't hurt to be aware at
an early stage just where monitor and guest data disagree;
another point would e.g. be the segment registers, where the
values in the guest_context struct should really contain the
*guest*'s idea of proper selectors -e.g. rpl 0- and not the
monitor's as they currently do.)
> Though that may be better taken care of by the kernel-level monitor...
> So okay, we could make this an ioctl call. But then, I guess
> you'd need to provide a similar system for breakpoints and
> such... the problem is that a breakpoint interface would
> be unusable by remote GDB, without weird hacks.
GDB uses remote memory access to write 'int 3' instructions?
Well, either we just do it that way and accept that this might
give interactions with certain guests, or else we'll have to
analyse those writes and convert them to monitor breakpoint
calls.
> > I was thinking about actions that originate with the GUI
> > but have global impact, like shutting down if the user
> > clicks the close box, or rebooting if the user clicks the
> > reboot icon, etc. These commands will need to be signalled
> > back to the main app.
>
> Well, I don't associate these with the GUI...
> powerdown, reboot etc. are processor actions.
> The GUI just calls them.
Well, yes, that's just what I was saying: there needs to be some
kind of routines in the main app that the GUI can call ;-)
Bye,
Ulrich
