#123876 - SpacedCowboy - Sun Apr 01, 2007 2:16 am
I've got gdb/desmume working on my mac (see previous post), but I'm still having problems with SWI statements... Can anyone take a peek at the following gdb session, and see if they've come across something similar ? I just don't get it :-(
I step through up until the call to testSWI(), then stepi through that call, and it seems to just completely ignore the swi statement (!)
the assembly for 'testSWI' is defined as:
... what I expected to happen was for the pc to be set to 0x08 and the ARM to jump through my vector to my handler code. I have that working for interrupts, the arm9 just doesn't seem to be processing SWI code (!)
Here's another gdb session, where I put a breakpoint at 0x08 (the SWI vector) and nothing gets called. When I put a 2nd breakpoint at 0x18 (the IRQ vector) that stops because I have VBLANK interrupts enabled...
So, I don't really see why SWI isn't working when the vector 16-bytes further on works fine. I was wondering if it was something to do with the arm/thumb routines that gcc seems to be jumping through... There is a call to testSWI in the inner loop of the test-app, by the way, so it ought to be jumping to the SWI vector over and over again!
Any help appreciated :-)
Simon
I step through up until the call to testSWI(), then stepi through that call, and it seems to just completely ignore the swi statement (!)
| Code: |
|
(gdb) step main () at template.c:49 49 testSWI(); Current language: auto; currently c (gdb) stepi 49 testSWI(); (gdb) 0x0200028c 49 testSWI(); (gdb) 0x02004ed4 in __testSWI_from_thumb () (gdb) 0x02004ed4 in __testSWI_from_thumb () (gdb) 0x02004ed8 in __testSWI_change_to_arm () (gdb) 0x02004ed8 in __testSWI_change_to_arm () (gdb) testSWI () at init.s:126 126 swi 0x8b8b8b Current language: auto; currently asm (gdb) 127 bx lr (gdb) 127 bx lr (gdb) main () at template.c:50 50 setUpScreen(); |
the assembly for 'testSWI' is defined as:
| Code: |
|
testSWI: swi 0x8b8b8b bx lr |
... what I expected to happen was for the pc to be set to 0x08 and the ARM to jump through my vector to my handler code. I have that working for interrupts, the arm9 just doesn't seem to be processing SWI code (!)
Here's another gdb session, where I put a breakpoint at 0x08 (the SWI vector) and nothing gets called. When I put a 2nd breakpoint at 0x18 (the IRQ vector) that stops because I have VBLANK interrupts enabled...
| Code: |
|
(gdb) break *0x08 Breakpoint 1 at 0x8 (gdb) target remote localhost:20001 Remote debugging using localhost:20001 _start () at ds_arm9_itcm0000_crt0.s:13 13 mov r0, #0x04000000 @ IME = 0; Current language: auto; currently asm (gdb) continue Continuing. ^C Program received signal SIGINT, Interrupt. 0x0200125a in _vfiprintf_r () (gdb) break *0x18 Breakpoint 2 at 0x18 (gdb) continue Continuing. Breakpoint 2, 0x00000018 in ?? () (gdb) disass 0x00 0x20 Dump of assembler code from 0x0 to 0x20: 0x00000000: b 0x24 0x00000004: b 0x28 0x00000008: b 0x64 0x0000000c: b 0x2c 0x00000010: b 0x30 0x00000014: andeq r0, r0, r0 0x00000018: b 0x3c 0x0000001c: b 0x34 End of assembler dump. |
So, I don't really see why SWI isn't working when the vector 16-bytes further on works fine. I was wondering if it was something to do with the arm/thumb routines that gcc seems to be jumping through... There is a call to testSWI in the inner loop of the test-app, by the way, so it ought to be jumping to the SWI vector over and over again!
Any help appreciated :-)
Simon