#24065 - JL - Tue Jul 27, 2004 9:25 am
Hi guys,
When using visual boy advance with tracing on, I get the following report in my trace.log when I start my code:
The list goes on, but this gives you the idea. When I objdump my .elf file the assembly code looks like this (it's in the play function for a modplayer which is written in C++ b.t.w.):
I compile with devkitadv5, and this particular snippet uses -O3. However, when I compile with no optimization the illegal write occurs at another position which looks like the same problem.
My question is, what is wrong with above code (how come it starts writing at 0 and upward each subsequent call)? With the little assembly I know, I don't see any clue for that to happen in this code...
Also what I find strange is that the bit flipping part (REG_DM1CNT ^=ENABLE_DMA) looks different in assembly for both of the calls although that might be the compiler optimizing.
Grtz,
Niels
When using visual boy advance with tracing on, I get the following report in my trace.log when I start my code:
| Code: |
|
Illegal halfword write: 0000 to 00000000 from 08002568 Illegal halfword write: 0000 to 00000002 from 08002568 Illegal halfword write: 0000 to 00000004 from 08002568 Illegal halfword write: 0000 to 00000006 from 08002568 Illegal halfword write: 0000 to 00000008 from 08002568 Illegal halfword write: 0000 to 0000000a from 08002568 Illegal halfword write: 0000 to 0000000c from 08002568 Illegal halfword write: 0000 to 0000000e from 08002568 Illegal halfword write: 0000 to 00000010 from 08002568 Illegal halfword write: 0000 to 00000012 from 08002568 |
The list goes on, but this gives you the idea. When I objdump my .elf file the assembly code looks like this (it's in the play function for a modplayer which is written in C++ b.t.w.):
| Code: |
|
void ModPlayer::play() { 8002558: e92d45f0 stmdb sp!, {r4, r5, r6, r7, r8, sl, lr} int i; signed short sample; // Flip the bit to disable the DMA REG_DM1CNT ^=ENABLE_DMA; 800255c: e3a02301 mov r2, #67108864 ; 0x4000000 8002560: e59240c4 ldr r4, [r2, #196] 8002564: e2241102 eor r1, r4, #-2147483648 ; 0x80000000 8002568: e58210c4 str r1, [r2, #196] // Swap the buffer where the DMA fetches the samples from REG_DMA1SAD = (u32)(myPlayBuffer1 ? myBuffer2 : myBuffer1); 800256c: e3a01f99 mov r1, #612 ; 0x264 8002570: e7d04001 ldrb r4, [r0, r1] // Flip the bit to enable the DMA again REG_DM1CNT ^=ENABLE_DMA; 8002574: e59280c4 ldr r8, [r2, #196] 8002578: e3540000 cmp r4, #0 ; 0x0 800257c: e1a0c000 mov ip, r0 8002580: e2287102 eor r7, r8, #-2147483648 ; 0x80000000 8002584: 1280ce13 addne ip, r0, #304 ; 0x130 8002588: e58270c4 str r7, [r2, #196] 800258c: e582c0bc str ip, [r2, #188] |
I compile with devkitadv5, and this particular snippet uses -O3. However, when I compile with no optimization the illegal write occurs at another position which looks like the same problem.
My question is, what is wrong with above code (how come it starts writing at 0 and upward each subsequent call)? With the little assembly I know, I don't see any clue for that to happen in this code...
Also what I find strange is that the bit flipping part (REG_DM1CNT ^=ENABLE_DMA) looks different in assembly for both of the calls although that might be the compiler optimizing.
Grtz,
Niels