> > With the last revision of the Hatari code (#d9c87d1f668d) it looks like
> > the symbol import and disassembly is now matching the sourcecode for my
> > case:
That's wierd, there were no changes that should have affected that.
I only did some minor changes to better support post-processor.
(Latest Python post-processor requires build of latest debugger code.)
Ok I didn't examine the changesets in any detail, but there were around 8 or 9 Mercurial changesets which arrived at once today. I figured something in there affected the TEXT offset stuff..... otherwise I'm not sure why it would import differently between tests.
I suggest we skip the CPU cache stuff and concentrate on CPU instruction
counts & cache misses + DSP instruction counts & cyles, and getting
the post-processing for them & symbols working for you propery.
That makes sense. I have been wary of the cache miss information because its harder to correlate with anything 'real' - there is no alternative source for it, and until the cycle counts look right I figured the cache miss stuff could be off too.
However if you think it's working I'll start working with it - but as I say it's very difficult to check independently..
I'll see how I get on with it.
Do you think there's some problem with the Devpac symbols converter?
The last test worked ok for me. I only inspected text symbols but I saw no pollution from data/bss in the text area.... so it looks like it is working.
D.