Re: [hatari-devel] Hatari profiler updates and CPU cycle questions

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On torstai 31 tammikuu 2013, Douglas Little wrote:
> > Do you see any compiler warnings from code under src/debug/ directory
> > if you rebuild those objects?
> 
> I saw no warnings to stdout/stderr while compiling... however I don't
> know if CMAKE is shuffling them to a logfile somewhere. Do you know if I
> should look elsewhere for warning output?

CMake doesn't hide warnings, just compiler lines.

I might try with LLVM v2.7 / Clang v1.1 to see whether it reports anything
extra, but that version (in Debian Stable) is really old, and typically
doesn't catch anything that GCC wouldn't catch.


> When you have extra time, you might try whether the bug goes away
> 
> > with -O1:
> > - if yes, please try also with -O2,
> > - if not, try with -O0.
> 
> I had tried this already, and the bug surfaces with any level above -O0
> (that is: -O/-O1, -O2, -O3)

Already at -O1?  Then it's probably when variables move from
stack to registers and some of them aren't in stack at all anymore.
Or it's because static variables layout changes.


> > That should give a fairly good pointer on whether and what what
> > kind of optimizations trigger the issue.
> 
> I had started subdividing the -fopts for -O but I didn't get very far
> before trying the patch (divided them in roughly half - and the bug still
> occurred). I can continue with that but GCC's optimization groups and
> overrides are very inconsistent and I would not be surprised to find it
> still happens even with all of the opts manually switched off. :-)

Based on the backtrace info you provided earlier, I think best option is
to set watchpoint to "optionPosAddress" variable to see when it changes.

When it gets non-zero value, it's smashed.


	- Eero