[hatari-devel] Conditional breakpoint code, please comment!

Eero Tamminen eerot at users.berlios.de
Mon Jun 15 20:36:46 CEST 2009


Hi,

On Monday 15 June 2009, Thomas H. wrote:
> > I think the attached patches should be pretty straightforward.
>
> Right, the 3 patches are quite small and look fine to me.

Thanks!  They're now commited so that others can test the breakpoint stuff
more easily.

Nicolas, could you test the conditional breakpoint stuff a bit and tell what
all I need to fix? :-)


Do you have any ideas how I could or should improve things e.g. in regards 
to variable naming, things I mentioned earlier mail, whether the CPU
register address thing should be in debugui.c (and not e.g. somewhere under
uae-cpu) etc?


Next I'm going to look into DSP memory access support.

Btw. The BITMASK macro is in three separate dsp*.c files and now also in
breakcond.c.  Which header it should be put into and should it have some
prefix?


> > There might be also other complicated things in Hatari which could
> > profit from regression tests, although writing automation code for them
> > (e.g. DSP)
> > could be quite complicated...  Do you think Hatari could in future have
> > automated test code for other stuff?
> >
> > (Just breakcond.c test code alone in tests/-dir could be silly.  :-))
>
> I currently don't think there is any other part of the code that would
> need automated test code... so I'd say to either keep the #ifdef'd main
> function in breakcond.c or keep it save on your hard disk.

Ok, I'll keep it in breakcond.c.

What about adding "test" "test-with-valgrind" targets to src/Makefile
that would build (things like) breakcond.c using "-DTEST=1" and run it?


	- Eero



More information about the hatari-devel mailing list