Kevin, thanks for your quick reply. I've sent this reply to the mailing
list, as I'm now discussing actual implementation issues.
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?
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.
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
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.
I also understand that the "hardware" devices will be designed such that
realistic timings could still be achieved even when running under the
debugger.
Am I in the right sort of area, or are there any areas here that I would
need to rethink?
Jules
At 10:01 AM 12/29/99 -0500, you wrote:
>The host OS specific part of FreeMWare is very small, with
>the idea that this project is designed to be extremely
>portable across all capable IA32 OSes. Currently we're
>focusing on Linux as a guest to keep development sane.
>When we get a decent set of guest virtualization working
>inside FreeMWare, we'll branch out and look to porting
>to other hosts OSes.
>
>What OSes are supported is limited only by the support
>that volunteers lend. So there's no reason we can't
>support your OS as a host or guest, if you help.
>
>There is a developer's email list available, or you
>can read it archived via web browsing.
>
>-Kevin
>
>
