[hatari-devel] DSP debugging and breakpoints
Laurent Sallafranque
laurent.sallafranque at free.fr
Fri Jun 5 00:21:59 CEST 2009
I won't change anything into debuggui.c for a few days (I'm not at home
for 3 days).
You can change everything you want here.
For DSP breakpoint, I thought at something like :
if (dsp_breakPoint == DSP_GetPC()) //DSP_GetPC() is already implemented
into dsp.c
//go to debug mode
}
The dsp_breakPoint would be set as suggested Eero : a new debug command
dbp <adress> // dbp = dsp breakPoint
PS : I just realized that this won't work, as we execute 7 DSP
instructions for 1 68030 instruction.
We wouldn't detect that we executes the DSP instruction at adress
<dsp_breakPoint>
Regards,
Laurent
npomarede at corp.free.fr a écrit :
> On Thu, 4 Jun 2009, Thomas Huth wrote:
>
>
>> On Thu, 4 Jun 2009 23:37:35 +0300
>> Eero Tamminen <oak at helsinkinet.fi> wrote:
>>
>>
>>> On Thursday 04 June 2009, Laurent Sallafranque wrote:
>>>
>>>> My question was : if the code arrives at the adress of my
>>>> breakpoint, I'd like hatari to go automaticaly to the debugger mode
>>>> (exactly as if I had pressed the "pause" key, but automatically).
>>>>
>>> Two alternatives:
>>> 1. DSP emu calls the debugger by itself (DebugUI())
>>> 2. DSP emu sets "breakpoint triggered" condition and returns
>>> back from DSP emu and Debug UI will then be called from the Hatari
>>> main code
>>>
>>> Thomas, what the SPCFLAG_BRK, SPCFLAG_TRACE & SPCFLAG_DOTRACE etc
>>> stuff in the UAE core is for?
>>>
>> Since we do not have breakpoint support for the normal 68k CPU yet,
>> there is also no infrastructure available yet which could easily be
>> used to implement breakpoint support for DSP. The SPCFLAG defines are
>> used for something different.
>> Sigh, is anybody working on the debugui.c code right now? If not, I
>> think I'll have a try, the incomplete debugger has really become a
>> bigger restraint during the past months...
>>
>> Thomas
>>
>
> Well, I had some idea about implementing some better debug features, such
> as breakpoints and single stepping, but I must admit I really don't have
> enough time to do it at the moment.
>
> But as I wrote in an older post, I think that in order to add more
> advanced debug features without dropping performance in normal case, we
> could create a new flag SPCFLAG_DEBUG for example.
>
> This way we can rapidly check in the main 68000 run loop if some special
> behaviours must be tested.
> This flag would allow a first stage "filtering" before testing for more
> complex case.
>
> for example :
>
> we already have this code in m68k_run_1 :
>
> if (regs.spcflags) {
> if (do_specialties ())
> return;
> }
>
>
> we could modify do_specialties to test for breakpoint/single stepping
> rather easily :
>
>
> static int do_specialties (void)
> {
> ...
>
> if (regs.spcflags & SPCFLAG_DEBUG) {
>
> if ( CheckForBreakpoint ( m68k_getpc() ) )
> {
> DebugUI();
> }
>
> else if ( CheckForSingleStep() )
> {
> DebugUI();
> }
>
> ...
>
> }
> ...
> }
>
>
> and when parsing hatari argument for example, we would set SPCFLAG_DEBUG
> if breakpoint arguments are given and/or single stepping is given.
>
> Just some possible thoughts to start, this of course require some more
> code to work.
>
>
> Nicolas
> _______________________________________________
> hatari-devel mailing list
> hatari-devel at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/hatari-devel
>
>
>
More information about the hatari-devel
mailing list