Re: [hatari-devel] Hatari debugger question

Hi,

I have one more, additional question relating to this. :)

The 'trace' feature reports events usefully, but it doesn't seem to report *where* they occur. There is no address information (see below). Trying to set conditional breakpoints on these to catch them in the same way as the CPU vectors won't work because they may be written without the value changing and some would get missed.

Is there a way to get trace to report addresses of the traced events?

Returning to emulation...

IO write.b $fffa19 = $00

IO write.b $fffa1f = $00

IO write.b $fffa07 = $3f

IO write.b $fffa13 = $3f

IO write.b $fffa1b = $00

IO write.b $fffa21 = $00

IO write.b $fffa07 = $3f

IO write.b $fffa13 = $3f

IO write.b $fffa1d = $50

IO write.b $fffa25 = $00

IO write.b $fffa09 = $74

IO write.b $fffa15 = $74

IO write.b $fffa17 = $40

On 10 August 2013 16:17, Douglas Little <doug694@xxxxxxxxxxxxxx> wrote:

Hi,

"trace io_write" did prove useful, thanks.

However I don't see an equivalent way to capture changes to the CPU vectors $0-$140. There does seem to be a comprehensive list of tracing axes but I can't tell if any of them overlap with these. Any suggestions?

(I did manage to do something similar by setting up conditional breakpoints on each one changing but it's a lot more effort than 'trace').

Thanks,
D.

On 10 August 2013 14:51, Eero Tamminen <oak@xxxxxxxxxxxxxx> wrote:

Hi,

On lauantai 10 elokuu 2013, Douglas Little wrote:
> Is there an easy way to trace all writes to a specific memory region?
> More specifically, writes to an interesting set of hardware registers,
> within some address range

Unfortunately, no.

> (Or even just all hardware registers - that would be nearly as good).

Yes: "--trace io_write".

> I'm trying to track down a conflict between two audio replay routines
> (SNDH replay, and separate DMA replay) and I'm not sure where the
> conflict is. The SNDH player is modifying some MFP or audio DMA state
> and I'd like to know where and why it needs to do this so I can make
> changes.

Interpreting trace of all IO writes is easier if you can:

* Somehow reduce the amount of traced code, by setting some
breakpoints where you start the tracing and where you end it.

* Provide debugger just symbols for functions that are relevant
for understanding what code could be doing the calls, and use
"cpu_symbols" tracing in addition to "io_write" tracing.

(just removing symbols for generic things that that get called
"too often" could be enough for that.)

- Eero