[ I've redirected the reply to port-i386 ]

> Hello folks,
>             I hope this is the right place for this... I need some
> tips on debugging at the user/kernel space line.
> 
> What I am trying to do is implement a v86 call so that NetBSD can
> support a DOS emulator.  Now I think that I have managed to do this,
> at least ddb tells me that my kernel routine is being run but soon
> after I get a SIGSEGV delivered to my test program.  Now this signal
> *could* be ok since the 80{3,4}86 machines use the GP trap to indicate
> the vm86 task found an instruction it thinks should be handled by the
> 80x86 (things like STI, CLI and the like).  My problem is that the
> signal does not get delivered until the user space is back in control
> which, I think, gives a bogus address, well not quite bogus it says
> the violation was the instruction before the lcall to the syscall call
> gate.  What I would like to be able to do is see the kernel address
> that caused the segv, how can I do this?  I tried putting a break
> point on trap but that caused an instant reboot... not surprising
> really.  Any ideas?
> 
So I guess you are adding a new sysarch() call that twiddles the VM86 flag
in the psw. One thing to be aware of is that the meanings of the selectors
change to segments. Take a look at the i386 Mach code to see some examples.

I suspect that some of this new meaning is causing the segv.

As far as debugging this stuff - I usually use printf()'s and intuition.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
 John Brezak                    UUCP:     uunet!apollo.hp!brezak
 Hewlett Packard/Apollo         Internet: brezak@ch.hp.com
 300 Apollo Drive               Phone:    (508) 436-4915
 Chelmsford, Massachusetts      Fax:      (508) 436-5103


------------------------------------------------------------------------------