[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