> I've had a look through the documentation & mailing list archives, and it
> doesn't seem to me as if anyone is working on debugging support, which is
> an aspect of the project that I would find very useful, even at this early
> stage of development. Is this correct?
Yes, indeed. I've been thinking along that lines myself ;-)
> If this is so, I would like to start work on it (although I can't promise
> that I'll have time to finish the job). The main experience I can bring to
> this is that part of the NASM package (which I am currently maintainer of)
> is the disassembler, NDISASM, which could probably be incorporated into the
> debugger package. This disassembler uses the Intel standard syntax for
> assembly language, rather than AT&T syntax. This is probably the better
> option for most people, in my opinion, as it is the more commonly used syntax.
Actually, I've already added a disassembler; check out user/decode.c ...
(B.t.w. my disassembler uses Intel syntax as well, but as text output is
separate from the actual instruction decoding, it would be trivial to add
an optional AT&T style output, if desired.)
> As for how it should work, my ideas are only sketchy at the moment, based on
> just a quick scan of the code so far (the 12/12/99 version; I haven't set up
> access to the CVS repository yet), but I guess this is along the correct
> lines:
>
> - new IOCTL calls are needed:
>
> - FMWSETBREAK to set a breakpoint
> - FMWCLEARBREAK to clear a breakpoint
> - FMWSTEP to single step an instruction
> - FMWUNTIL to execute instructions up to a given point
I'm not sure new IOCTLs are needed; can't this be done from user space?
User space does have full access to the guest's memory, so setting/clearing
breakpoints is just a matter of inserting 'int 3' as usual; for single-step
mode, the user program could simply set the trap flag in the guest context
(this is currently filtered out by the kernel, but it could be let through
without problems).
The rest of the debugger features (run until ..., break after n repetitions,
etc.) can be build on top of the primitives, as debuggers usually do. As to
hardware-assisted debugging, that won't work for now, but sooner or later
we'll have to support guest use of the debug registers anyway, and once this
is implemented, we can simply let user access the (simulated) guest debug
registers, probably as part of the guest context.
> As I understand the setup at the moment, the virtual machine's state is
> stored in memory allocated by the user space program, so the debugger would
> have no problem in accessing the guest system's memory and registers
> whenever execution stopped.
Correct. (You do have to implement segmentation/paging yourself, though.)
> I also understand that the "hardware" devices will be designed such that
> realistic timings could still be achieved even when running under the
> debugger.
Probably yes ...
Anyway, if you want to start adding debugger support, I'd suggest you get
the latest CVS version, as this contains enough emulation code to actually
run the 'cooperative' kernel. Being able to single-step though this guest
would really be interesting ...
Bye,
Ulrich
--
Ulrich Weigand,
IMMD 1, Universitaet Erlangen-Nuernberg,
Martensstr. 3, D-91058 Erlangen, Phone: +49 9131 85-7688
