Hi,
On keskiviikko 15 toukokuu 2013, Douglas Little wrote:
I have a bug which I'm trying to catch in Hatari. It would be easier to
solve if the debugger could be invoked when a DSP exception occurs - in
this case DSP illegal instruction. I'm not sure how to configure this
myself so I need some advice.
In the time I have been working on this project I've seen 3 different
bugs which result in the same fault (usually buffer overrun, corrupting
code) and had to modify the code to self-debug. This is usually quite
arduous so I'd rather just catch it on the first event.
Worse... when it happens Hatari tends to lock up - it streams thousands
of lines like this:
Dsp: 0x0329: 0x000dc0 Illegal instruction
Dsp: 0x0329: 0x000dc0 Illegal instruction
Dsp: 0x0329: 0x000dc0 Illegal instruction
Dsp: 0x0329: 0x000dc0 Illegal instruction
Dsp: 0x0329: 0x000dc0 Illegal instruction
And then freezes, requiring the process to be killed. This makes
debugging it even more difficult since I can't interrupt it.
------ dsp_cpu.c ---------
/* If yes, stack overflow, underflow and illegal instructions messages are
not displayed */
static bool isDsp_in_disasm_mode;
...
static void dsp_undefined(void)
{
if (isDsp_in_disasm_mode == false) {
cur_inst_len = 0;
fprintf(stderr, "Dsp: 0x%04x: 0x%06x Illegal
instruction\n",dsp_core.pc, cur_inst);
/* Add some artificial CPU cycles to avoid being stuck in an
infinite loop */
dsp_core.instr_cycle += 100;
}
else {
cur_inst_len = 1;
dsp_core.instr_cycle = 0;
}
---------------
Laurent, why isDsp_in_disasm_mode has effect on this? Why one would
NOT want to be informed of these kind of issues when disassembling?
As above code zeros cur_inst_len (without changing DSP PC address),
DSP will at this point loop on that address until CPU side
pushes something else to that DSP memory area. In practice latter
most likely won't happen as illegal instruction is an error in program.
I.e. Hatari will output those messages in continuous stream, which
doesn't benefit anybody and should IMHO be fixed to do something
more reasonable.
Because instruction cycles are added, CPU side should still progress
and therefore Hatari should still stay (somewhat) interactive
despite huge amount of printfs.
Douglas, if you remove that printf (or make it appear only once),
does Hatari still freeze? If yes, could you use debugger to see where
it freezes?
Is there any way to do get the debugger invoked when this occurs? Or can
I have suggestions on a local patch I can make to get this effect?
Pull latest Hatari updates from repo. With -D option, undefined/illegal
DSP instructions & stack under/overflows invoke debugger:
http://hg.tuxfamily.org/mercurialroot/hatari/hatari/rev/9b76d896bef4
As TOS will do some CPU side exceptions, I recommend enabling these
in debugger only after TOS has booted:
setopt -D
history on
When debugger is invoked, check instruction history leading to the issue.
- Eero