Re: [hatari-devel] debugger suggestions

[Toni Wilen <twilen@xxxxxxxxxx>]

> > I am wondering if the following breakpoint conditions can be added:
> >
> > 1) break on memory address access rw (b, w or l).
>
> This is a common wish.
>
> Nicolas?
>
> (It would need CPU core to update variables that store last read and write access addresses, and a bit of code on debugger side to to support setting breakpoints on their values, and to zero their values before continuing emulation from debugger.)

UAE redirects memory "bank" that has "memory watch point" configured to debugger routine which checks if access matches breakpoint (address match, size match, data or instruction fetch, data matches, etc..) and then it calls original memory access function. No need to change CPU emulator and introduce performance loss even when break points are not active.

> While that would be nice, there are several issues:
>
> * Hatari has currently 2 disassemblers, one provided by the CPU core itself, and "ext" one
>
> * Nowadays disassembler in (Amiga) WinUAE CPU core is more important (it has better instruction support), but that is a separate project from Hatari
>
>
> Toni (maintaining WinUAE) would need to add callback support to WinUAE disassembler for replacing addresses with corresponding symbol names.
>
> Then after WinUAE disassembler has all the features provided by "ext" disassembler, we could drop the "ext" one.

UAE disassembler already supports optional symbols, it calls debugmem_get_symbol(<pc/any calculated effective address>) and if it returns string, it gets appended to disassembly.