Debugger32 doesn’t ‘run’ on its own.
if it is installed in a boot image, then when the system executes a
int 0xf3 (from user code (see inline.h) or from the keyboard (ctrl-atl-esc)
or a kernel/handler fault) then the kernel sets some state and jumps
to the Debugger32 code.
if you are never invoking an int 0xf3 then you are never running the
Debugger code.
but the fact you include it in your image means that your memory map is
slightly different, and processes may start at different addresses in
physical memory than before.
something that i do (even with a photon system) is enable the debugger
for use over a serial port.
e.g.
/boot/sys/boot
$ boot -v
/home/randy/cvs/qnx4/Proc/bin/Proc
$ Proc32 -vv -P26 -l 68 -t500 -o 3f8,57600 -D
/boot/sys/Slib32
$ Slib32
/boot/sys/Slib16
$ Slib16
/bin/Fsys
$ Fsys -r2M
/bin/Fsys.eide
$ Fsys.eide
/bin/mount
$ mount -p /dev/hd0 /dev/hd0t77 /
/bin/sinit
$ sinit TERM=qnxm
/boot/sys/Debugger32
$ /boot/sys/Debugger32 -s 0x3f8 -b 57600 -zs
then attach a terminal on 3f8 at 57600 … make sure that if you start up
Dev.ser in your sysinit that you DO NOT let it take over ser1 @ 3f8. Proc
itself and the Debugger have their own(shared) serial code for talking thru
the port.
because i start Proc with -vv this means that any program (including my
own) that uses qnx_display_* calls will also appear on the serial port.
and at any time i can invoke the debugger either by having a piece of root
code do a int 0xf3 or do ctrl-alt-esc from the console (non photon).
once in there i can use all the debugger tools to look at memory …
at the qnx conference we went thru some detailed qnx4 debugging scenarios.
these are available in:
/usr/free/qnx4/os/development/sysdbg.tgz
my personal feeling is that you have some bad memory in there that is causing
the hard lockup. the fact that the same system runs fine without the debugger
means that only the memory locations should be changing.
John Parsons <parsonsj@esi.com> wrote:
Hi All,
Does anyone know what Debugger32 is doing during normal operation when
normal system code is running. We have a condition where are code will
lock at different times and under different conditions, but always in
the same location in the code. We have added Debugger32 to the boot
image and we are no longer seeing the lock condition. So Debugger32
must be running something in the background that changes our run
condition in some way. If we know what Debugger32 is doing in the back
round we may be able to determine our runtime fault.
Thanks
John
–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579