[hatari-devel] CPU breakpoints and single-stepping

Eero Tamminen eerot at users.berlios.de
Sun Jun 7 23:24:51 CEST 2009


Hi,

On Sunday 07 June 2009, Thomas Huth wrote:
> > I think I'll first add similar kind of breakpoints & single stepping
> > for DSP as you added for CPU and then start working on the break
> > condition support (first as separate code debugUI).
>
> Well, I just had another idea: instead of re-creating such a complex
> framework for conditional breakpoints, why don't we simply use gdb
> instead? As far as I know, gdb can also connect to virtual machines (or
> external devices) through a stub. For example it is possible to use gdb
> with QEMU to debug the program that is running within QEMU (I never used
> this, though).

I think this is for the user-space qemu which runs single processes.

If you do the same with system qemu (which is closer to Hatari), you
would be debugging the whole thing which makes single process debugging
quite tedious/impossible (context switches...).  For debugging processes
in such an environment it's much better just to run Gdb server within the
emulator and connect to that from outside the emulator with host cross-Gdb.


> gdb has already conditional breakpoints as far as I know, and a lot of
> other nice features - even source code debugging might be possible!

Seeing source code/line info with Gdb assumes that:
- You have matching binaries with debug symbols for Gdb.
- Gdb understands binary format and the debug symbols in your binaries.
  (on Atari would mean that the binaries would need to be built with gcc?)


> Has anybody a clue what would have to be done to connect a 68k gdb to
> Hatari?

You provide the Gdb remote debugging (gdb server) socket/serial/etc API
into which Gdb can connect to.

Gdb would need to support the architecture which you want to debug, also in
cross mode.  From MiNT list i've understood that for 68k this is fine (one
can use gdbserver inside Aranym and run cross-Gdb on host), but not for
DSP... And with Hatari you may want to debug both at the same time.

I think this debugger work is more important for the DSP as that you cannot
very well debug even with native Atari debuggers like one might be able to
do for m68k side.


> > > Well, but then you could only step one instruction. What if you
> > > want to skip 100 instructions? With my current implementation, this
> > > is possible...
> >
> > Good idea.  -> I'll keep separate single stepping.
> >
> > Btw.  What do you think of the issue of multiple breakpoints vs.
> > multiple break conditions?
>
> I agree with Nicolas that it might be useful to have multiple
> breakpoints - comes in very hand if you want to remove just one
> breakpoint and not the whole breakpoint condition.

Ok.  Attached is a start on conditional breakpoint handling.
Handling of different addressing modes did / will make the code
a bit bloated.

(It builds but is otherwise untested.)


	- Eero
-------------- next part --------------
A non-text attachment was scrubbed...
Name: breakpoint.c
Type: text/x-csrc
Size: 8442 bytes
Desc: not available
URL: <https://lists.berlios.de/pipermail/hatari-devel/attachments/20090608/7c32dd8b/attachment.c>


More information about the hatari-devel mailing list