It seems the symbols are not mapping to the correct addresses for some reason. It happens not just in the disassembly process but
any _expression_ evaluated in the debugger (i.e. it is consistent).
Having imported the symbols, and using the following test:
(from symbol file) 000004C4 T Doom
> evaluate text+$4C4
= %11101010100101000 (bin), #120104 (dec), $1d528 (hex)
> disasm $1d528
Doom:
$01d528 : 6100 22d8 bsr $1f802
$01d52c : 6100 23bc bsr $1f8ea
$01d530 : 48e7 8080 movem.l d0/a0,-(sp)
....and comparing with the source code...
*-------------------------------------------------------*
* Program starts here *
*-------------------------------------------------------*
txtlong
*-------------------------------------------------------*
Doom: move.l 4(sp),a5
lea 128(a5),a4 ; command string
move.l a4,cli
*-------------------------------------------------------*
* Mshrink *
*-------------------------------------------------------*
move.l 12(a5),d0 ; text segment
add.l 20(a5),d0 ; data segment
add.l 28(a5),d0 ; bss segment
Performing a full disassembly and scrolling through the output shows similar problems...
bls.b end_test_blocks_scan
dbf d7,test_blocks_scan_line
end_test_blocks_scan
rts
Calculate_Distance:
move.w vtx_x(a1,d2.w*4),d3 ; x2
sub.w vtx_x(a1,d1.w*4),d3 ; x2-x1=dx
move.w d3,dx ; dx
muls.w d3,d3 ; dx^2
...from the debugger disasm....
$023dce : e848 lsr.w #4,d0
$023dd0 : 1c31 0000 move.b (a1,d0..w),d6
$023dd4 : d68c add.l a4,d3
$023dd6 : 3e30 6a00 move.w (a0,d6..l*2),d7
$023dda : d244 add.w d4,d1
$023ddc : 2003 move.l d3,d0
$023dde : 3cc7 move.w d7,(a6)+
Calculate_Distance:
$023de0 : 3001 move.w d1,d0
>
$023de2 : ec88 lsr.l #6,d0
$023de4 : 3cc7 move.w d7,(a6)+
$023de6 : e848 lsr.w #4,d0
$023de8 : 1c31 0000 move..b (a1,d0.w),d6
$023dec : d68c add.l a4,d3
Finally, the crazy numbers for cycle counts are still apparent (note: 4294967295 decimal = 0xFFFFFFFF)
$024062 : 0813 0000 btst #0,(a3) 0.13% (51276, 4294967295, 823)
$024066 : 67fa beq.s $24062 0.13% (51276, 4294967295, 1)
$024068 : 3611 move.w (a1),d3 0.01% (2176, 4294967295, 1362)
$02406a : 6b00 0110 bmi $2417c 0.01% (2176, 4294967295, 0)
$02406e : 4bf9 0018 676a lea $18676a,a5 0.01% (1972, 0, 0)
$024074 : 4281 clr.l d1 0.13% (49980, 4294967295, 49973)
$024076 : 0813 0000 btst #0,(a3) 0.13% (49980, 4294967295, 96011)
$02407a : 67fa beq.s $24076 0.13% (49980, 4294967295, 3)
$02407c : 3211 move.w (a1),d1 0.13% (49980, 4294967295, 49979)
$02407e : 41f4 3200 lea (a4,d3.w*2),a0 0.13% (49980, 4294967295, 3)
..since this the latter is happening in a pure debug build, it's unlikely GCC is causing it IMO. It may be contributing to the 'crash' but not this second issue.
The symbols thing may just be a simple bug or invalid assumption on our part about the Devpac symbol table (or even invalid symbol table at the source itself???). In any case it can probably be figured out with a bit more time prodding. I just happen to be quite short of time this week or I'd be more methodical - just doing very quick tests as I am able.
The CPU cycle count thing is a bit worrying.
Note also that the DSP cycle counts looked ok without any wild numbers (not tried symbols yet for that - will do as soon as I can).
D.