COST CENTRE MODULE no. entries %time %alloc %time %alloc
MAIN MAIN 1 0 0.0 20.3 0.0 100.0
main Main 172 30590380562441576 0.0 19.0 0.0 19.0
CAF Main 166 30590376291721096 0.0 20.2 0.0 20.2
main Main 173 0 0.0 0.0 0.0 0.0
dude Main 174 30619204112395264 0.0 0.0 0.0 0.0
Sadly, for some reason it's also getting corrupted with the via-c build, so my usual approach of swapping out suspect -fasm closure code for known good -fvia-c code isn't going to fly.
That puts me squarely in GDB territory, and the nastiness of breakpoints and single stepping through instructions. I figure GDB is like the SWAT team of software engineering. It's fun to recount its exploits to your pals over beer, but you hope you're never in a situation where you actually need to call on its services.
Anyway, some time later I've got a Cmm line:
I32[CCCS] = CAF_ccs;
I64[I32[R1 + 4] + 16] = I64[I32[R1 + 4] + 16] + 1 :: W64;
or %g1,%lo(Main_CAFs_cc_ccs),%g1 -- ok, load CAF_ccs into %g1
or %g2,%lo(CCCS),%g2 -- ok, load addr of CCCS into %g2
st %g1,[%g2] -- ok, I32[CCCS] = CAF_ccs
add %g1,1,%g1 -- hmmm: produce a misaligned addr into %g1
addx %g2,%g0,%g2 -- hmmm: a nop. %g0 is always zero
ld [%l1+4],%g3 -- ok, load addr of the cost centre record into %g3
add %g3,16,%g3 -- ok, calculate the addr of the allocation count
-- for that cost centre
st %g2,[%g3] -- badness! write addr into the allocation count field
st %g1,[%g3+4] -- ditto
Finding being 80% of fixing, hopefully this'll be working again tomorrow.