[hatari-devel] dsp trace instr

[Eero Tamminen]

Hi,

On sunnuntai 20 maaliskuu 2011, Laurent Sallafranque wrote:
> I've reworked the DSP disasm and trace modes.
> It seems to work well now.

Looks good to me.


> I've tested it a lot, but don't hesitate to do some tests too.
> 
> I've improved it at the same time :
> - no more stack messages (overflow or underflow) in disasm mode on RTI
> and other instructions
> - illegal instruction become dc opcode in disasm mode
> - dc instructions are displayed with 0 cycles
> 
> Now, you can mix trace mode and illegal mode as you want.

What are the differences between DSP trace & disasm modes and
when one would use which of them?

-> This information should be in Hatari manual debugging section,
   under its own DSP debugging subsection I think.


> 2 questions :
> 
> - Do you think that trace dsp_registers and trace dsp_memory should be
> added to the debugguer or should they stay as DEFINES and recompilation
> in dsp_cpu code ?

How often they're needed compared to the normal disassembling?

Both add a check to speed-critical DSP function, but memory tracing
would need also switching an often used auxialiary function at run-time.


> - Is there a way to use the debugguer like this ?
>         db pc=$'value' and then trace the N next lines of DSP code
> 
> DSP debugging sorts so many lines, I's like to be able to just display
> the N next lines after pc = a value, or after a certain register reach a
> value, ...

You can set a breakpoint to the condition you like with the ":info" modifier
and then use the "lock file" info command to give/lock a file containing
the debugger commands that you want to be run[1] when the breakpoint is hit.

In above case the file should in theory be something like:
	trace dsp_disasm
	cont 5
	trace none

But here's a similar problem as with your DSP disassembling.
Within the breakpoint, the CPU core flag for entering debugger is set,
so CPU core returns immediately to debugger instead of continuing for
5 instructions.

For now all you can run from breakpoint is the trace command, rest of
the actions you unfortunately need to do from the debugger prompt yourself.


[1] Even if the continue issue would be fixed, there's a second problem,
that the locked command (in this case parsing a debugger commands file)
would be executed also when debugger is re-entered, i.e. it would loop
recursively forever continuing.

To fix that:
1. breakpoints would need to use something else than the "lock" command
2. the CPU & DSP cores and debugger need to be fixed so that it's possible
   to continue (for given number of steps) before getting back to debugger

Regarding 1), on retrospect I think the ":info" breakpoint flag wasn't so
hot idea because one might have multiple breakpoints on which he might want
different actions to be executed.  I could at some point change it to
":file <file>" flag that allows specifying a separate debugger commands file
for each breakpoint.

As to 2), that would indeed be a nice feature... :-)   It might also help
in enabling breakpoint usage from Python UI (haven't really thought
about that).


	- Eero