armand@sm14.ec.bull.fr (Armand HORNIK) (08/20/90)
I am working on a ISC 2.0.2, building some telecommunications driver and
I would
like to call the kernel debugger (for debugging usage) from my driver.
Does anibody know how to do it ?
Thanks in advance
Armand HORNIK
Regards,
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Armand Hornik
Email : armand@sm14.ec.bull.fr Centre UNIX Bull SA
Phone : +33 76 39 75 00 Ext 7357 1, Rue de Provence
Fax : 011-33-76397600 B.P. 208
38432 ECHIROLLES CEDEX / FRANCEstevea@i88.isc.com (Steve Alexander) (08/23/90)
In article <433@echbull.bull.fr> armand@sm14.ec.bull.fr (Armand HORNIK) writes: >call the kernel debugger (for debugging usage) from my driver. I think you can issue the call debugger(0, (long *)0) from within your code. I've done a similar thing under AT&T 3.2* on occasion, and it can be very helpful. The first argument is a trap code, and shouldn't be non-zero, since that would cause some things to happen that might assume that your second argument is valid. The second argument is the value of the saved frame pointer, which you probably don't have since you're not the trap processing code. Among other things, a non-zero first argument causes the debugger to disassemble and display the instruction at the saved IP location when you enter the debugger via a panic. Debugger(0, (long *)0) is basically how the kd driver gets into the debugger when you issue a CTRL-ALT-D (K_DBG) request. Hope this helps. Good luck. [*] Under AT&T 3.2 and 4.0, the debugger entry point is called _debugger, and it only takes the first argument. It obtains the saved frame pointer via other means. Systems using the GDEBUGGER have a different entry point, which I have never used. -- Steve Alexander, Software Technologies Group | stevea@i88.isc.com INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea