Subject: How to find out what instruction really caused a sigsegv
To: Technical Kernel Mailing List <tech-kern@sun-lamp.cs.berkeley.edu>
From: Brett Lymn <blymn@mulga.awadi.com.AU>
List: tech-kern
Date: 01/23/1994 18:05:40
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?

-- 
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
===============================================================================
"Where a calculator on the ENIAC is equipped with 18,000 vaccuum tubes
and weighs 30 tons, computers in the future may have only 1,000 vaccuum
tubes and perhaps weigh 1 1/2 tons."
                -- Popular Mechanics, March 1949

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