#84387 - simonjhall - Mon May 22, 2006 10:08 am
Hi, I'm new to homebrew on the DS (but not new to console programming) and I've noticed the lack of a debugger...
Just a quick question - does anybody want one? Or does everyone develop their programs inside one of the emulators (which would allow single-instruction stepping), then once it's working test it out on the real target?
Cos if there is demand for a (real) debugger, I've got a version 0.01 of a little project y'all might like :-)
#84392 - HyperHacker - Mon May 22, 2006 10:22 am
I wouldn't mind seeing one. My debugging method right now consists of adding more text to the output and/or blinking the power LED. :-p
_________________
I'm a PSP hacker now, but I still <3 DS.
#84400 - simonjhall - Mon May 22, 2006 11:37 am
Anyone else?
Plus - how much does the ARM 7 get used? Cos at the moment I can only debug the ARM 9 and adding support for the '7 would be a bit trickier (as stalling it would halt the networking...)
Plus 2 - how much does the THUMB mode get used? Again, adding support for that may be non-trivial (though to be fair, I've not looked into it properly).
#84403 - Wuschmaster - Mon May 22, 2006 12:11 pm
I'm interested.
By the way, is it possible to add a "take screenshot" feature? That would be damn cool, dude.
#84404 - simonjhall - Mon May 22, 2006 12:20 pm
As in capture what's currently on the LCD? Well if the data at the address of the framebuffer is readable (as in not write-only) then capturing the framebuffer(s) should be easy as pie!
Another idea I've been toying with is loading executables straight onto the target across the wireless link... Isn't the speed like 2MBit though? So filling 4 megs of RAM could be a bit sluggish. Pulling files from the PC's filesystem should be easy too. Wireless printfs (for those who swear who by debugging with printfs!) work well.
#84418 - GPFerror - Mon May 22, 2006 1:46 pm
| simonjhall wrote: |
Hi, I'm new to homebrew on the DS (but not new to console programming) and I've noticed the lack of a debugger...
Just a quick question - does anybody want one? Or does everyone develop their programs inside one of the emulators (which would allow single-instruction stepping), then once it's working test it out on the real target?
Cos if there is demand for a (real) debugger, I've got a version 0.01 of a little project y'all might like :-) |
Source code debugger? like wireless gdb? that would be awesome. Or gdb support in dualis would be nice as well. This is one of my most requested features that would make development alot easier :)
Troy(GPF)
http://gpf.dcemu.co.uk
#84423 - simonjhall - Mon May 22, 2006 1:56 pm
Yeah, I'm talking about stepping through real code running on a real DS in GDB (I'm using GDB plugged into Eclipse).
#84426 - GPFerror - Mon May 22, 2006 2:03 pm
would love to test it, i have eclipse. If you need a tester or are you releasing soon?
Thanks,
Troy(GPF)
http://gpf.dcemu.co.uk
#84438 - agentq - Mon May 22, 2006 4:34 pm
I'd be very interested in seeing this. It would be great to be able to trace through ScummVM, and have a networkable printf. Also, being able to reload the executable over the wireless would save a lot of wear and tear on my slot.
My main worry would be the extra memory used by the stub, and the extra memory used by compiling my program without optimisations.
#84443 - simonjhall - Mon May 22, 2006 4:51 pm
| agentq wrote: |
| Also, being able to reload the executable over the wireless would save a lot of wear and tear on my slot. |
Heh, slot.
| agentq wrote: |
| My main worry would be the extra memory used by the stub, and the extra memory used by compiling my program without optimisations. |
At the moment, the stub is around 100k, though the bulk of that is from bits of libnds and libwifi I'm not using. Gonna (eventually) try and strip out the bits that aren't needed. Also if you're already linking with these libraries it's only gonna add like 20k to the size of the executable.
Yeah, I suppose compiling your own code without an -O of some kind may make your code bigger. You could -O some bits of code and -g the bits you really wanna poke at...
| GPFerror wrote: |
| would love to test it, i have eclipse. If you need a tester or are you releasing soon? |
Ta, but it's still a way from being properly testable. I'll get back to you... In the meanwhile me and my buddy aqentq (who I conveniently know in the Real World) may try running it on his baby to weed out the major bugs I'll inevitably have.
#84446 - agentq - Mon May 22, 2006 4:56 pm
So you're that Simon J Hall?! I never suspected.
#84447 - simonjhall - Mon May 22, 2006 5:03 pm
| agentq wrote: |
| So you're that Simon J Hall?! I never suspected. |
Well you are the 'new guy', so I guess you wouldn't know who I am. People have been talking about your dodgy name ever since you started... Post coming for Mr A Q does attract attention, y'know :-p
#84448 - agentq - Mon May 22, 2006 5:14 pm
Yeah, well I like to live life on the edge... of unemployment.
#84454 - Mighty Max - Mon May 22, 2006 6:06 pm
Yes, we'd love it :D
Currently my main debugging mean is a memory dump to CF at crash (exception). If i'd had something to browse through, change and continue, that would be great!
_________________
GBAMP Multiboot
#84455 - wintermute - Mon May 22, 2006 6:28 pm
| simonjhall wrote: |
Anyone else?
|
Yes, very. I'm in the process of updating the Insight package provided by devkitPro. I'd be very happy to add such a project to the devkitPro CVS as well - I've just started looking at the feasability of doing exactly this with Insight/gdb over wifi but I hadn't yet started on code.
| Quote: |
Plus - how much does the ARM 7 get used? Cos at the moment I can only debug the ARM 9 and adding support for the '7 would be a bit trickier (as stalling it would halt the networking...)
|
Quite a lot but I'd say most people would be happy enough with just debugging arm9.
| Quote: |
Plus 2 - how much does the THUMB mode get used? Again, adding support for that may be non-trivial (though to be fair, I've not looked into it properly). |
thumb mode is the default for the devkitPro examples and templates so probably quite a bit.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#84456 - wintermute - Mon May 22, 2006 6:30 pm
| Mighty Max wrote: |
Yes, we'd love it :D
Currently my main debugging mean is a memory dump to CF at crash (exception). If i'd had something to browse through, change and continue, that would be great! |
change and continue?
You've been a bit spoiled by the VS debugger haven't you?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#84457 - simonjhall - Mon May 22, 2006 6:30 pm
| Mighty Max wrote: |
| Currently my main debugging mean is a memory dump to CF at crash (exception). If i'd had something to browse through, change and continue, that would be great! |
That's interesting... What kind of crash are you talking about? And how do you catch it? eg if you were to divide by zero, would you be able to catch that?
#84458 - Mighty Max - Mon May 22, 2006 6:33 pm
I have that debug on any abort (Jump to or read/write invalid addresses, everything that calls an exception vector other then reset, irq or swi)
or on key irq to check for endless loops via a key-combination.
Wintermute: indeed :D
_________________
GBAMP Multiboot
Last edited by Mighty Max on Mon May 22, 2006 6:34 pm; edited 1 time in total
#84459 - simonjhall - Mon May 22, 2006 6:34 pm
| wintermute wrote: |
| I've just started looking at the feasability of doing exactly this with Insight/gdb over wifi but I hadn't yet started on code. |
Ooh ooh! Please don't steal my thunder and do it before me!
Anyway - I was having a bit of trouble finding a gdb which has arm as it's target. I tried Insight from devkitPro, but whenever I loaded in any elf the program would just crash... Any ideas? Since then I've been using a gdb from another source...
#84460 - wintermute - Mon May 22, 2006 6:36 pm
| simonjhall wrote: |
| Mighty Max wrote: | | Currently my main debugging mean is a memory dump to CF at crash (exception). If i'd had something to browse through, change and continue, that would be great! |
That's interesting... What kind of crash are you talking about? And how do you catch it? eg if you were to divide by zero, would you be able to catch that? |
The exception code in the BIOS looks like this
| Code: |
sub_FFFF00C0 ; CODE XREF: ROM:loc_FFFF001Cj
MRS SP, CPSR
ORR SP, SP, #0xC0
MSR CPSR_cxsf, SP
LDR SP, =0x27FFD9C
ADD SP, SP, #1
loc_FFFF00D4 ; CODE XREF: ROM:FFFF0134j
STMFD SP!, {R12,LR}
MRS LR, SPSR
MRC p15, 0, R12,c1,c0
STMFD SP!, {R12,LR}
BIC R12, R12, #1
MCR p15, 0, R12,c1,c0
BIC R12, SP, #1
LDR R12, [R12,#0x10]
CMP R12, #0
BLXNE R12
LDMFD SP!, {R12,LR}
MCR p15, 0, R12,c1,c0
MSR SPSR_cxsf, LR
LDMFD SP!, {R12,LR}
SUBS PC, LR, #4
; End of function sub_FFFF00C0
|
the ARM vectors at these addresses point to this code
0x00000004 Undefined instruction
0x0000000C Prefetch Abort Abort
0x00000010 Data Abort
so these exceptions will eventually jump to the address stored in 0x27FFD9C
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#84464 - simonjhall - Mon May 22, 2006 6:46 pm
wintermute: Cool, that's pretty much what I want. I'll get back to you when I wanna do it proper :-)
At the moment the program breaks into my breakpoint-handling code by simply replacing the chosen instruction with a bl to my handler. It's then gotta save everything itself, rather than let the exception-handling mechanism do it for me.
max: I also thought about change and continue, but yeah - you'll be lucky! One thing at a time...
#84466 - wintermute - Mon May 22, 2006 6:52 pm
| simonjhall wrote: |
| wintermute wrote: | | I've just started looking at the feasability of doing exactly this with Insight/gdb over wifi but I hadn't yet started on code. |
Ooh ooh! Please don't steal my thunder and do it before me!
|
Heh, this one is a task I'm perfectly happy to let someone else do the hard work
| Quote: |
Anyway - I was having a bit of trouble finding a gdb which has arm as it's target. I tried Insight from devkitPro, but whenever I loaded in any elf the program would just crash... Any ideas? Since then I've been using a gdb from another source... |
There's the Insight package linked to from http://www.devkitpro.org/downloads.shtml under the Visualboy Advance section. I haven't yet got around to updating the one used by the installer as there were still some weird problems which turned out to be VBA's fault. I'll be updating soon, I just haven't decided whether to go with the forthcoming 6.5 or one of the CVS builds I've been doing.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#84470 - mastertop101 - Mon May 22, 2006 7:12 pm
What type of information could we get from it ? Would it send complicated errors and/or ram dumps ? or interpreted errors ?(with possible causes...)
#84490 - HyperHacker - Mon May 22, 2006 10:12 pm
ARM7 does all sound and wireless and handles input from the touch screen, X and Y buttons, I believe a few other things as well. In a simple app it's generally just checking for instructions to write power management regs, enter GBA mode etc at VBlank, but it does make up 33% of the DS's processing power, so it does a fair bit of work in more complex apps. In official games it's always running a binary supplied by Nintendo, and I can't say how much processing power that uses, if you even intend to support those.
_________________
I'm a PSP hacker now, but I still <3 DS.
#84547 - simonjhall - Tue May 23, 2006 7:36 am
Cool, I'll think about supporting the ARM 7. I suppose I'd be able to suspend the main thread of execution but breaking into interrupts on either processor is likely to be a no-no.
Plus debugging a real game? If you could somehow load in my code THEN execute the game it'd work - as long as the game loads itself into RAM first. Debugging ROM will not work as this is software debugging, and it requires write access to the code being debugged.
#84555 - Mighty Max - Tue May 23, 2006 9:15 am
For non-write to code breakpoints you cound use a protection region.
If you map a 4kB region, RW Access but Execute disallowed, you'll have an exception everytime a opcode in that 4kB wants to be done. As this enters another mode on the ARM, you can backup all register contents fairly easy. After this, copy the command to a region you can control, enter debug or set all registers, as you were in that 4kB region, execute this opcode, store the registers again, and leave the exception.(if it is some other address in this region)
It's slow as hell for this 4kB but hey, its debugging, and only needs done for code in the rom area.
You can btw do the same for data access breakpoints (i.e. break if a variable gets written) by disallowing writes/reads from that area, and calculate the fault address, disable the region, enter debug or execute the opcode causing the fault (if its some other value in this region) , and then reset the region.
_________________
GBAMP Multiboot
#84558 - simonjhall - Tue May 23, 2006 11:01 am
| Mighty Max wrote: |
| You can btw do the same for data access breakpoints (i.e. break if a variable gets written) by disallowing writes/reads from that area, and calculate the fault address, disable the region, enter debug or execute the opcode causing the fault (if its some other value in this region) , and then reset the region. |
Bangin'. I was looking for a decent way of doing watchpoints that didn't involve stepping one instruction at a time and checking for a change. That method would do just fine.
May have to put the debugger on hold for a few days though as my new sax has just been delivered to work in a big-ass box :-)
#84656 - simonjhall - Tue May 23, 2006 11:13 pm
Ok, it's progressing. I was thinking of showing a screenie but a) people might say I've faked it and b) I'm not too sure of where to host a picture.
Anyway, I've been thinking about this ARM 7-related stuff and one thing struck me whilst doing a test debug: I can't inspect any variables from the ARM 7 binary. It's cos I've only loaded the ARM 9 ELF :-)
So, anyone have any suggestions of how I can load a second ELF (or at least the symbol table) into GDB? I can't seem to get the two loaded side-by-side; either the second one isn't 'noticed' or adding a second one replaces the first. Also, not too sure on how it'd work anyway what with the duplicated symbols! (eg there's two main() functions)
A summary of the current status:
- placing breakpoints works well
- variable inspection works great
- traversing the stack seems to work
- most registers can be inspected
- stepping works ok (only puts next breakpoint at pc+4 - doesn't handle jumps)
- continuing doesn't work well, as GDB is inconsistent with regards to when it wants to place or delete a breakpoint
- less TCP packets going walkies due to better error detection
- it is a bit slow...
Lots more left to do!
#84661 - agentq - Tue May 23, 2006 11:30 pm
I thought your Sax was going to take up your spare time?
But anyway, the debugger sounds like it's going really well.
#84677 - HyperHacker - Wed May 24, 2006 2:37 am
| simonjhall wrote: |
| Ok, it's progressing. I was thinking of showing a screenie but a) people might say I've faked it and b) I'm not too sure of where to host a picture. |
Screw them, and Photobucket or Imageshack.
_________________
I'm a PSP hacker now, but I still <3 DS.
#84700 - simonjhall - Wed May 24, 2006 9:22 am
Was a bit over-zealous with the posting last night, here's more!
What's cool:
- figured out GDB's way of breakpointing, so stepping and continue work just fine
- much faster than before, stepping is dog-slow though due to the amount of network chit-chat required
- still only steps pc+4
- register inspection works properly now (it didn't before)
- inspecting variables from other stack frames works well
- more network reliability fixes when under 'heavy load'
- good integration with Eclipse's debugger
What's not cool:
- there's the ocassional race condition whilst stepping, and the PC-side hangs
- when entering a new stack frame, Eclipse tells GDB to disassemble the code from memory, not from disk. GDB then does this 4 BYTES AT A TIME! You then have to wait whilst it downloads the code at a snails pace!
- a similar thing happens when inspecting variables (in particular arrays/structures) - it likes to download then 10 bytes at at time. Not good.
- there's gotta be more stuff that's broken
I'm at work at the mo, so no screenshot love, sorry!
#84713 - chishm - Wed May 24, 2006 11:06 am
Wow, this will be very helpful. I normally debug by printing to screen, but this will make it so much easier. Keep up the good work, and hopefully I'll know how to use GDB when it's released. :D
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#84748 - 0xtob - Wed May 24, 2006 3:44 pm
I agree, a wireless debugger would save a lot of time and frustration with debugging. It's awesome that someone is tackling this task and seems to be having quite impressive progess.
Keep it up!
#84761 - wintermute - Wed May 24, 2006 4:37 pm
#84841 - GPFerror - Wed May 24, 2006 11:34 pm
yes looks like its coming along nicely, can't wait :)
thanks for working on this.
Troy
#84852 - simonjhall - Thu May 25, 2006 12:36 am
| GPFerror wrote: |
| thanks for working on this. |
No problem. It is kinda for fun - I've never written a debugger or anything like it before :-) I'm just shocked at how well it's going!
For the fun of it, here's a screenshot of the thing running. NOTE: I've grabbed the whole (dual-screen) desktop so you 1024x768-ers will need to scroll (really sorry) and 56k users - just don't bother!
[Images not permitted - Click here to view it]
In the far left console is the PC-side of the debugger, the bit which translates the commands from GDB into something easily understood by the DS stub.
On the right screen I'm running Eclipse's debugger: I just jab F11 and it automatically runs the arm gdb, connects to the PC stub and jumps into debug mode.
I'm running the third demo (modified slightly) from the nehe examples for libnds.
Important things to notice (yeah, I'm spelling it all out - but what the hell!):
- when running normally, the quad on the right of the top display (of the DS) spins
- I've suspended execution at the draw function by dumping down a breakpoint just before running glLoadIdentity
- the image on the top display (of the DS) has now frozen
- Eclipse then asks GDB for a disassembly of the current function, which then asks the PC stub, which then asks the DS for the relevant info
- the PC stub has actually crashed :-) If you look in the disassembly at the selected line and the following line it would normally show the real opcodes, but as something has broken, the breakpoints haven't been deleted and the hooks into the debugger stub are visible!
Oh and unrelated: the speed of the thing has now improved, esp when it comes to downloading big chunks of memory. Before it used to take 45 secs to download and disassemble main(), and now it takes eight-ish... Single-stepping is much faster but still sluggish - I've not yet worked on that properly.
EDIT: And yeah, the Konfabulator weather widget is right - it IS raining here in Sunny London :-( Better not on my jolly commute 2mo morn though...
#85147 - simonjhall - Sat May 27, 2006 1:23 pm
Here's a quick update on the debugger before I go away for the weekend...
- Breakpoint handling is now pretty perfect (ie stepping and continuing etc). No more duplicate 'points or deleting breakpoints twice.
- There was a bug where I'd get confirmation of a breakpoint write yet the program wouldn't halt there - I reckon this was a cache problem as flushing the d-cache fixed that (touch wood!)
- Still can only step pc + 4; I reckon I need to verify the registers are correct first before I can calculate branch targets.
- Networking is still a bit flakey. May change to UDP.
- Memory writes work ok (eg variable changing).
#85150 - wintermute - Sat May 27, 2006 1:51 pm
| simonjhall wrote: |
- There was a bug where I'd get confirmation of a breakpoint write yet the program wouldn't halt there - I reckon this was a cache problem as flushing the d-cache fixed that (touch wood!)
|
you might want to also invalidate the instruction cache at the address.
| Quote: |
- Networking is still a bit flakey. May change to UDP.
|
UDP communciation isn't guaranteed to arrive. If it's already flaky with TCP then it'll get worse if you do that.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#85284 - simonjhall - Sun May 28, 2006 6:08 pm
| wintermute wrote: |
| you might want to also invalidate the instruction cache at the address. |
Is that using CP15_FlushICache()? I did a really quick test of that, yet I couldn't figure out which library I had to link with (ie I got linker errors). But anyway, I think it's sorted now I'm flushing the data cache. Still would feel better flushing the instruction cache too!
| Quote: |
| UDP communciation isn't guaranteed to arrive. If it's already flaky with TCP then it'll get worse if you do that. |
The thing is I'm doing loads of network checking/checksuming/verifying/resending etc and I assumed that by cutting out the stuff that TCP does (as I'm doing it all myself) it might make it run a bit quicker. Is DS UDP any good, or is it really lossy?
Oh and I think I'm *nearly* ready to get people to try this :-) It's pretty reliable, and literally the only thing I need to write now is the mechanism to step into branches, rather than just over them.
Oh and quick question - r0 is a real register, right? I can do stuff with it, yet GDB never asks for its value and always insists that it's zero... Also, are there any fp registers?
Oh #3 - I've got some readahead mechanism to allow you to download/disassemble big chunks of memory faster (as GDB normally disassembles 4 bytes at a time) so now disassembling my demo function has gone from 45->15->2 seconds!
#85295 - GPFerror - Sun May 28, 2006 7:33 pm
| simonjhall wrote: |
| Oh and I think I'm *nearly* ready to get people to try this :-) |
Can't wait, thanks for working on this :)
Troy(GPF)
http://gpf.dcemu.co.uk
#85580 - simonjhall - Thu Jun 01, 2006 12:02 am
Here's the low down on what's been happening with the debugger:
Had a very quick go at figuring out why the networking is so slow, but didn't have a lot of luck. Gonna try and fix this at some later date. Basically, there's some mondo lag in there, but I'm not even too sure whether it's my DS' fault or PC's fault! Still reckon datagrams are the way forward.
Also had a very quick go at ARM7-ing, but only to see if you could read variables from the ARM7 app. So the stub listens to two sockets - a GDB for the regular ARM9 code and one for a GDB for the ARM7 code. You guessed it, two debuggers controlling one program (with no real way of halting the '7) doesn't give good results - but you can inspect variables on the second processor (they just change a lot)! I'll think about real '7 support some other time.
THUMB - I'm pretty sure I stepped into some thumb code earlier (as it hung), yet it doesn't look like thumb to me... Here's an example: stepping into glTranslatef is cool, but that bx doesn't execute properly (it hangs). Even though it's branching to a 4-byte aligned address it still stops... Ah, who cares. This is the whole function definition btw, so I have no idea what's going on here!
| Code: |
0200024c <__glTranslatef_from_arm>:
200024c: e59fc000 ldr ip, [pc, #0] ; 2000254 <__glTranslatef_from_arm+0x8>
2000250: e12fff1c bx ip
2000254: 02002b81 andeq r2, r0, #132096 ; 0x20400 |
And now the real work,
EASY: It no longer steps to the next address in memory, it'll handle b/bl/bx jumps properly as well as all conditionally executed instructions. So you can now step into functions, rather than straight over them :-) Needs more testing (esp the cond instrs) to verify that it's cool.
HARD: The tiny stub which launches into the debugger needed to be totally rewritten as it only worked in 95% of cases, ie it worked as long as the instruction you're stepping into didn't touch the link register. But now it's cool (I hope). Ta Neil for the chit-chats 'bout this today. Say 'no' to acid.
#85587 - The 9th Sage - Thu Jun 01, 2006 1:51 am
| simonjhall wrote: |
Plus debugging a real game? If you could somehow load in my code THEN execute the game it'd work - as long as the game loads itself into RAM first. Debugging ROM will not work as this is software debugging, and it requires write access to the code being debugged. |
Huh, there must be a way to load a gamecard after loading some homebrew into RAM...Dipstar (the NDS cheat program) does this. Not sure about getting the game to send out the wireless though, I'm sure that'd take a LOT more hacking.
_________________
Now with 20% More Old Man from Zelda 1 than ever before!
#85588 - dexter0 - Thu Jun 01, 2006 2:22 am
Sorry if I missed this but....
Is this going to have to be compiled with your game (during the time you are debugging of course) or will it be similar to dipstar?
#85611 - simonjhall - Thu Jun 01, 2006 9:28 am
| dexter0 wrote: |
| Is this going to have to be compiled with your game (during the time you are debugging of course) or will it be similar to dipstar? |
Originally the plan was to make it so that all you have on your CF card (or whatever you use to boot) was the stub which loaded in an elf over the network and then allowed you to debug it. But due to the network *currently* being too slow (but still kudos to the guy who did the wifi) you've gotta link your app with my stuff then call a function or two to allow debugging.
Gonna look into wireless booting once I figure out why my thing's so sluggish.
Actually, if you wanted to have both the stub and your app as separate apps on your card it wouldn't be TOO hard to load the stub first then load in the app... Pointless though, as you'd need extra loading code...and I'm too lazy to piss about with that!
#85749 - dexter0 - Fri Jun 02, 2006 4:13 am
To Bad. I was hoping to use it to help search for DipStar codes.
#87042 - josath - Sun Jun 11, 2006 6:38 pm
might want to try latest version of the wifi lib updates. maybe he's fixed the slow wifi problem (i've had the same problem as well before, where ping time goes up, and transfer speeds go slow)
#87633 - simonjhall - Wed Jun 14, 2006 9:25 pm
Yo, just wanted to say to those people who are still after a debugger that this thing IS still going on, it's just that I've been snowed under by work! Programming SIMD asm for eight hours a day, then coming home to program even more just hurts your brain!
I'm totally ready to have this thing tested btw - and now would have been an ideal time - but I'm off to CVPR all next week! So sorry guys, you're just gonna have to wait a little longer!
Stuff which is coming, soon
- faster
- *source-stepping* (rather than one opcode at a time)
- no more race conditions locking the thing up :-)
- the option to reset the target
- if I have time: maybe a simple UI to separate all the console output (like an SN target manager if you've ever used one) and some buttons to control the pc-side stub
Maybe I should take my laptop on the plane :-)
EDIT: could I request having an arm-eabi-gdb in the next devkitarm? Just updated and I don't think there's one there...
#87640 - wintermute - Wed Jun 14, 2006 10:02 pm
I've tested vba & arm-elf-insight with the elfs from the new toolchain - it all seems to work as expected.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#90351 - simonjhall - Thu Jun 29, 2006 8:49 pm
Ok, back from NYC and now I think I'm ready to have *a few* people test the debugger. So *a couple* of people who might have experience with low-level stuff wanna step forward? :-) You're gonna need to be comfortable with hex and looking at ARM assembler! Knowledge of gdb would kick ass greatly.
This is still pretty WIP, it's just that I've not had half as much time to work on it as when I originally started writing it... Just need some people to motivate me to finish it!
And Millstone, you're just too slow :-p
NOTE: the final thing ain't gonna require you to look at hex or assembler, this is just so you can confirm it's working correctly...
#90923 - simonjhall - Mon Jul 03, 2006 2:47 pm
I WILL be releasing this soon - I promise! Just still need a bit of testing done (will send out testing ver shortly to some people).
BUT as I have a big ol' bug which only appears once in a blue moon I need to rewrite a critical bit of code in order to fix it. If I do rewrite it though I'm thinking of adding support for THUMB at the same time.
Now here's my problem - how can I tell for a given instruction if it's a THUMB instruction or an ARM instruction? Yeah, I can check the alignment but that won't work for all instructions. Anyone have any suggestions? Ta :-)
Anyway, here's a refresh of what this thing can currently do, for those who don't wanna read the rest of this thread:
- suspend ARM code running on the ARM9, allowing you to inspect memory/registers/variables/the stack etc
- write to memory, but not registers (yet)
- you can read/write ARM7 data that is in the main memory space - but the ARM7 can't be suspended at the moment so the values could be wrong
- step into/over individual instructions *in user-space code* (ie not interrupts etc)
- step into/over whole lines of source code - the big thing I've been working on
- blacklisting of functions which won't be stepped into (eg so you don't accidently hang the debugger by stepping into itself)
Coming soon:
- a released version :-)
- hopefully transparent support for both THUMB and ARM code
- the ability to catch erroneous memory accesses (eg NULL pointer exceptions)
I'm reluctant to add support for register writing and adding the ability to restart execution from a different instruction. Wouldn't be hard though, I just think it'll make it really easy for people to crash their programs... I also don't really want to add memory watchpoints either as it sounds like a world of pain!
Anyone have any special requests for stuff to be added?
#90946 - tepples - Mon Jul 03, 2006 6:06 pm
| simonjhall wrote: |
| Now here's my problem - how can I tell for a given instruction if it's a THUMB instruction or an ARM instruction? Yeah, I can check the alignment but that won't work for all instructions. |
I think bit 0 of the program counter is set when the CPU is in Thumb mode.
| Quote: |
| - step into/over individual instructions *in user-space code* (ie not interrupts etc) |
So that means you can't use the debugger if your game loop is structured like Super Mario Bros. (NES), where the entire game after the init code is one big vblank handler, right?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#90954 - wintermute - Mon Jul 03, 2006 6:17 pm
| tepples wrote: |
| simonjhall wrote: | | Now here's my problem - how can I tell for a given instruction if it's a THUMB instruction or an ARM instruction? Yeah, I can check the alignment but that won't work for all instructions. |
I think bit 0 of the program counter is set when the CPU is in Thumb mode.
|
Doesn't help much for setting breakpoints.
I believe gdb should tell you if it's trying to set a breakpoint in thumb code or in arm code. I haven't really looked into the details of how source code stepping is acheived.
You should be able to get away with assuming that code which is currently thumb will still be thumb unless you encounter instructions which modify the program counter ( bx, blx etc)
| Quote: |
| Quote: | | - step into/over individual instructions *in user-space code* (ie not interrupts etc) |
So that means you can't use the debugger if your game loop is structured like Super Mario Bros. (NES), where the entire game after the init code is one big vblank handler, right? |
If you allow nested interrupts then you should be able to get away with that.
Simon: I'd like to take a look at what you have working so far.
Feature request: zero dependencies on cygwin
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#90960 - simonjhall - Mon Jul 03, 2006 6:45 pm
| wintermute wrote: |
I think bit 0 of the program counter is set when the CPU is in Thumb mode.
|
Yeah, I read that in the docs. Yet when I disassemble the code from disk, all the code is aligned to 2-byte or 4-byte boundaries. Maybe the final bit of the pc is set but it doesn't affect anything when the cpu fetches the next instruction (if you know what I mean)...
| wintermute wrote: |
Doesn't help much for setting breakpoints.
|
If all I gotta do is test one bit and write a THUMB-specific breakpoint function then it should be easy! (touch wood)
| wintermute wrote: |
If you allow nested interrupts then you should be able to get away with that.
|
Can't believe people can write a game in a v-blank handler :-)
But yeah, the only reason it might not work in an exception handler or an interrupt is if interrupts get turned off. Basically anything which prevents the wifi from talking to the PC-side stub is a bad thing.
This is another reason why I'm wary of adding support for the ARM7 - I'm worried that if someone dumps down a breakpoint in the wrong place it'll hang the wifi.
And I'll add you to the list of people I'm gonna send a test version out to if you like. And no, it's not dependent on cygwin. The GDB I currently use is one from the codesourcery site, but it works very well with Insight from devkitpro... It also talks to Eclipse fine too! Can you tell I'm running out of things to write?
#90963 - Dark Knight ez - Mon Jul 03, 2006 7:03 pm
| Quote: |
| Can't believe people can write a game in a v-blank handler :-) |
I did. As to give the background music decoding engine more time and being able to see that as one giant program... it would be hard to divide that program into small fragments, whereas the regular game is already divided in fragments (of less than a frame).
#90976 - tepples - Mon Jul 03, 2006 7:54 pm
| simonjhall wrote: |
| Can't believe people can write a game in a v-blank handler :-) |
It's not that hard. Converting a game loop to a vblank ISR involves 1. converting your game loop into the following form, 2. adding a reentrancy guard in stuff() (or alternatively making sure that it never exceeds a million ARM9 cycles in the worst case), and then 3. setting stuff() as your ISR.
| Code: |
//Frame call normal form
void play(void) {
while (!done) {
vsync();
stuff();
}
} |
| Dark Knight ez wrote: |
| I did. As to give the background music decoding engine more time and being able to see that as one giant program... it would be hard to divide that program into small fragments |
GSM audio comes in frames. MPEG audio also comes in frames. So do tracker formats, where the "tempo" effect controls how many frames happen in 2.5 seconds. What audio format were you trying to decode?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#91003 - Dark Knight ez - Mon Jul 03, 2006 10:12 pm
I'm using the IT format played by libmikmod.
The current setup works like a charm. It was a surprise to hear some other games have set it up like this as well.
#91019 - simonjhall - Tue Jul 04, 2006 12:21 am
I've changed my breakpoint function so that it now runs part of it in an exception handler when the bkpt instruction is called (causes a data abort exception on a machine without debug hardware). The code works, and that big bug I had before has gone, but I've got some beef with a cache.
Basically the thing now works by hitting a bkpt instrucion, which then goes into the exception handler to save the program counter (the hardest bit to save). It then replaces the bkpt instruction with a jump to the real breakpoint handler which does all the rest of the work. The exception handler then breaks and returns to the original program counter to hit the jump to the bp handler.
*Except* it keeps hitting the original bkpt opcode over an over again. It might do this ten times or a thousand times until the real jump is hit. I've tried flushing the data cache, but that isn't doing anything. I'm not too sure on how to flush the instruction cache.
Yet if I read what's at the breakpoint address just before I write the new one, I can confirm that the right value has been written (somewhere), it's just that the old instruction keeps getting run... (so, i-cache?)
I'm using a modified version of Mighty Max's exception handling code (well, I think it's his!).
Here's the code which gets me in:
| Code: |
EnterException:
// store context
LDR r12,=ExceptionLocalStorage
STMIA r12,{r0-r11,r13}
// assign a stack
LDR r12,=ExceptionStack
LDR r13,[r12]
// Get C function & call it
LDR r12,=ExceptionC
LDR r12,[r12,#0]
ADD r14,r15,#0
BXNE r12
// restore context
LDR r12,=ExceptionLocalStorage
LDMIA r12,{r0-r11,r13}
// do the bios code
.word 0xE8BD5000
.word 0xEE01CF10
.word 0xE16FF00E
.word 0xE8BD5000
.word 0xE25EF004 |
and here's my code:
| Code: |
int hit_count = 0;
void Exception(void) {
EnableMPU() ; // without, console code accessing other mirrors fail
//iprintf("Exception occured:\n") ;
switch (GetCPSR() &0x1F) {
case 0x1B:
// Undefined instruction occured
break ;
case 0x17:
// General Protection Fault
if (*(volatile unsigned int *)0x027FFD98 == 0)
{
printf("zero - not good\n");
while(1);
break;
}
printf("hit count %d\n", hit_count++);
int rewritten_opcode = compute_jump(*(volatile unsigned int *)0x027FFD98 - 4, debugger_hit);
int hit_address = *(volatile unsigned int *)0x027FFD98 - 4;
*(volatile unsigned int *)hit_address = rewritten_opcode;
break ;
default:
iprintf(" reason: unknown (%02X)\n",GetCPSR() &0x1F) ;
while(1)
break ;
} ;
return ;
} ; |
#91026 - gladius - Tue Jul 04, 2006 1:41 am
"mcr p15,0,r0,c7,c5,0" will do a complete Icache flush. You can do specific regions at a pretty small granularity as well, check out the arm9 docs on mcr to see how to do it.
#91029 - wintermute - Tue Jul 04, 2006 2:57 am
as it happens, instruction cache functions have been added to CVS libnds
http://devkitpro.sourceforge.net/devkitProWiki/libnds/a00030.html
see icache.s for code
you might also like to take a look at the exception handler API in libnds - it needs extended a little bit to be able to return from an exception though. I haven't got around to decoding the instruction sequence that Mighty Max inserted as raw data.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#91060 - simonjhall - Tue Jul 04, 2006 10:15 am
| gladius wrote: |
| "mcr p15,0,r0,c7,c5,0" will do a complete Icache flush. |
That did the trick perfectly, thanks. It also worked if I disabled the i-cache or the d-cache (or both), but I wasn't happy with that solution...
Disassembling this code,
| Code: |
.word 0xE8BD5000
.word 0xEE01CF10
.word 0xE16FF00E
.word 0xE8BD5000
.word 0xE25EF004 |
gives:
| Code: |
ldmia sp!, {ip, lr}
mcr 15, 0, ip, cr1, cr0, {0}
msr SPSR_fsxc, lr
ldmia sp!, {ip, lr}
subs pc, lr, #4 ; 0x4 |
Ok I can't crash/deadlock it now, so I'm now gonna clean up the code, slap on some license and copyright junk and release version 0.1 to my testers :-)
No THUMB yet btw.
#91097 - Mighty Max - Tue Jul 04, 2006 4:08 pm
You can tell if the exception is caused by thumb or arm code by checking the T-bit in SPSR.
You can utilize the opcode 0xBExx (BKPT) to cause a prefetch abort in thumb. (ARMv5t)
---
I decided to put in the raw words instead of the decoded instruction, was a problem with a false decode that kept crashing. It was the fastest solution.
_________________
GBAMP Multiboot
#91157 - wintermute - Tue Jul 04, 2006 11:08 pm
Any particular reason you copied the bios code rather than just using mov pc,lr after restoring the registers?
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#91158 - mastertop101 - Tue Jul 04, 2006 11:20 pm
or will it work? we'll need to patch our Nds file? it's going to be into a custom firmware? etc.?
#91159 - Mighty Max - Tue Jul 04, 2006 11:24 pm
| wintermute wrote: |
| Any particular reason you copied the bios code rather than just using mov pc,lr after restoring the registers? |
To be honest, i have to admit, i had some problems understanding those 4 lines and i saw no reason to get stuck there if the simple bandaid solution works *g* Never came around to check it again after that ...
Problems in understanding those lines where the unaligned access to the storage and the movs to restore the old cpu mode. I should have read more in the references.
_________________
GBAMP Multiboot
#91208 - simonjhall - Wed Jul 05, 2006 9:24 am
| mastertop101 wrote: |
| or will it work? we'll need to patch our Nds file? it's going to be into a custom firmware? etc.? |
Do you mean how are you going to have to use the debugger? Technically I've not ruled anything out regarding how you can use it. Here's the options I currently got on the cards:
- linking each app you wanna debug with the debug stub library and then call the setup functions and you're off, with the wireless command polling function in the main update loop (easy, the current method)
- patching executable files with the required changes (hard, a lot of work for no real gain)
- a tiny NDS file which pulls the real NDS over the network, inits the debugger, installs the update function in a timer and starts the app (may be unreliable)
Anyway, I've figured out how to find out if I should write an ARM breakpoint or a THUMB bp now. I'm just trying to decide whether to write that then release it, or just do THUMB at a later date...
#91291 - Abcd1234 - Thu Jul 06, 2006 3:55 am
It strikes me that an earlier release is probably better. At least then you can get some code out that people can run away with and hammer at.
'course, I'll be the first to admit that my opinion is motivated by at least a little selfishness... I'm rather excited about the idea of interactively debugging my NDS apps. :)
#91334 - simonjhall - Thu Jul 06, 2006 2:39 pm
| Abcd1234 wrote: |
At least then you can get some code out that people can run away with and hammer at.
|
I've got to admit, I'm really worried about this! I know that if I put it out there that a) people are gonna have a million problems with it and will require me to solve them and b) if it's not finished when I release v0.1 then people are gonna moan even more! So that'd prob why I keep delaying it.
| Abcd1234 wrote: |
| I'm rather excited about the idea of interactively debugging my NDS apps. :) |
I have to say, the very first time I got my demo program to make and stop at a breakpoint, delete it then resume I jumped for joy and bounced around the room, grabbed my housemate (a girl who has no idea what a debugger is) and started yelling stuff at her!
The novelty has now worn off. Probably because I've had to rewrite the core breakpoint algorithm twice :-(
Anyway :-) I tried compiling the app last night with -O1 and -O2 last night just to see how it breaks and yeah, it breaks quite nicely. Sorry guys, but you're gonna have to wait again! The good news is that I got stepping to run faster - ~0.6 seconds/opcode when instruction stepping, ~0.4/opcode when line stepping. It's this slow because I still have the wireless sitting on that 50ms timer...
#91382 - EyeballKid - Thu Jul 06, 2006 9:11 pm
| simonjhall wrote: |
| I know that if I put it out there that a) people are gonna have a million problems with it and will require me to solve them and b) if it's not finished when I release v0.1 then people are gonna moan even more! So that'd prob why I keep delaying it. |
I wouldn't worry too much - I think you'd get a lot more positive feedback and good ideas than negative criticism and moaning. I'd just ignore anything negative unless it's accompanied by a patch to fix it :- )
I say release early, release often!
#91399 - masscat - Thu Jul 06, 2006 11:53 pm
simonjhall - you have done something that nobody else has and something that will be very useful to many people, so release it and be happy. Some people will moan about bugs and the like but many more will be very positive, appreciative and helpful.
It is a strange feeling to release a personal project (especially releasing the source) as people will find bugs and scrutinise your work but having other people find your work useful is a good and you have to release at some point so if it is in some working state it may as well be now. Also, many times, other people's input will improve the project and help motivate you to continue.
On an aside: from this specification, the DS has a serial port hidden somewhere inside it. Now if this could be found then it would allow a debug connection without the overhead/problems of the wireless interface.
#91410 - simonjhall - Fri Jul 07, 2006 1:02 am
Ta man, thanks for the encouragement.
If it makes y'all feel better, I'm writing the (currently pretty long) readme right now.
It's gonna go to a few select testers first to weed out the obvious bugs and then out to the general public.
Slightly off topic, anyone wanna donate some web space for me to host this thing? Preferably a site with other DS homebrew too rather than ftp.genericfreehosting.com/user1234afdf/ etc.
Oh and I reckon a name for this thing, "Yet Another DS Debugger".
Who wants to beat that? :-D
#91427 - GPFerror - Fri Jul 07, 2006 4:11 am
| simonjhall wrote: |
Ta man, thanks for the encouragement.
If it makes y'all feel better, I'm writing the (currently pretty long) readme right now.
It's gonna go to a few select testers first to weed out the obvious bugs and then out to the general public.
Slightly off topic, anyone wanna donate some web space for me to host this thing? Preferably a site with other DS homebrew too rather than ftp.genericfreehosting.com/user1234afdf/ etc.
Oh and I reckon a name for this thing, "Yet Another DS Debugger".
Who wants to beat that? :-D |
I would love to help test and would be willing to host it on my site http://gpf.dcemu.co.uk
Im pretty familiar with gdb debugging I use it on the dreamcast and on the pc, just not familiar with asm.
Troy(GPF)
#91576 - dovoto - Sat Jul 08, 2006 12:22 am
I also have room to host if needed
_________________
www.drunkencoders.com
#91649 - simonjhall - Sat Jul 08, 2006 3:43 pm
Thanks guys for the hosting offers - I'll get back to you. I'm gonna temporarily host it on my ISP space (which I didn't know I had) for a short while though.
Right - I'm gonna send out some testing versions in a couple of hours to weed out the really obvious problems people are gonna get.
But as I know people never read readmes and this isn't your average NDS when you have no need to know how it works, I reckon I ought to put up the instructions now just to make sure people read them :-)
Check it out, it's pretty big:
http://myweb.tiscali.co.uk/simonhall/README.txt
You're gonna wanna read it in something that has line wrapping, eg notepad.
And don't bother hunting for the real thing on that site as there's nothing else there!
EDIT: it's now gone out to a bunch of people
#91727 - simonjhall - Sun Jul 09, 2006 1:14 am
For those people who are testing it, I've already fixed one big-ass bug, cleaned up a bunch of code (builds with g++ now) and got it building with ScummVM.
So shout if you're getting unexpected results when stepping beq/bneq etc.
#92229 - Ryan FB - Wed Jul 12, 2006 5:48 am
Works for me, and I'm booting the demo via WMB and my default WFC connection uses 128-bit WEP.
My only major complaint is that the Java stub needs privileged ports (<=1024) which on a *nix system means you have to run it as root.
#92329 - simonjhall - Wed Jul 12, 2006 9:04 pm
For those in the know, any idea why I can't get my exception handler to catch invalid instructions/bad memory access/breakpoints in THUMB mode?
When there's an exception, the chip is supposed to switch to ARM mode then branch to your exception handler, ya? Whether I have the handler installed or not, the machine locks if I throw some kind of exception. When in ARM mode however if I don't have the handler installed the chip just carries on. But in THUMB it'll crash regardless!
Anyone got any ideas? Or have Nintendo 'customised' this chip?
----
I was thinking of killing off the exception-based breakpoint system but I realised that in THUMB b/bl instructions can only get you +/-2k (?) which is a bit pants. So I'm either gonna hafta get this exception stuff to work or dot your binary with breakpoint-helper functions!
----
| Quote: |
| Works for me, and I'm booting the demo via WMB and my default WFC connection uses 128-bit WEP. |
Thanks for letting me know, I'll update the readme (for v0.12).
#92340 - Mighty Max - Wed Jul 12, 2006 10:02 pm
Breaking from Thumb mode worked just fine for me, but i guess you are then using thumb code (generated from compiler) in the exception too (the actual handler after the jumb can have both formats).
In case of thumb, it is likely that it does some stack operations before you reenable the MPU, which then crashes. Fix: call the EnableMPU from the assembler before you enter the custom handler.
Erm ... nevermind the handler has an independent stack. But try enabling the MPU earlier anyways
_________________
GBAMP Multiboot
#92342 - wintermute - Wed Jul 12, 2006 10:46 pm
Have a look at the exception handler code in libnds and the exception test demo, that works fine for me with thumb code.
Exception handler
Exception test
The error display code
As it happens I'm considering just shifting to arm mode for libnds - while thumb is more size efficient and you get a hit from the 16bit ewram for arm mode the cache makes up the difference quite well.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#92343 - Mighty Max - Wed Jul 12, 2006 11:28 pm
:) It's time for me to switch to the newer releases ... im just lazy when it comes to such *g*
Btw wintermute, you know i am not much caring about what ppl do with code i give out to the public. But reading through the licence gives me a bad feeling. "you must not claim that you wrote the original software." is a rule i obviously break on some of the lines in these files.
_________________
GBAMP Multiboot
#92352 - wintermute - Thu Jul 13, 2006 12:43 am
| Mighty Max wrote: |
:) It's time for me to switch to the newer releases ... im just lazy when it comes to such *g*
Btw wintermute, you know i am not much caring about what ppl do with code i give out to the public. But reading through the licence gives me a bad feeling. "you must not claim that you wrote the original software." is a rule i obviously break on some of the lines in these files. |
Not sure what you mean here. Using libnds doesn't magically make your code our work - the clause is intended for people who want to distribute modified versions of the library and direct people to the right place for contributing changes back to the main project.
The exception handler code is based largely on the work you did, I just haven't got around to adding your name into the source in CVS yet.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#92407 - Mighty Max - Thu Jul 13, 2006 12:31 pm
late in the night, a worrying missread, just ignor me ;)
_________________
GBAMP Multiboot
#92560 - dovoto - Thu Jul 13, 2006 10:20 pm
| wintermute wrote: |
As it happens I'm considering just shifting to arm mode for libnds - while thumb is more size efficient and you get a hit from the 16bit ewram for arm mode the cache makes up the difference quite well. |
Can the cache hold twice as many thumb instructions as arm ? If so it seems like you might be effictivly reducing your instruction cache by a factor of two and slowing down ewram access by choosing arm over thumb. I may just be confused :)
_________________
www.drunkencoders.com
#92566 - masscat - Thu Jul 13, 2006 11:06 pm
Good work on the debugger - a very useful tool to have (no more printing to the console).
I was wondering why you use the Java stub and do not just connect GDB directly with the DS.
Somewhat selfish reason for asking - I was thinking about building a RS232 port using the SPI IO of the DS card slot with a micro controller to do the SPI UART bridge. If your DS debugger stub accepts GDB Remote Serial Protocol commands then to debug over the serial port would only require changing the packet read/send functions on the DS.
And why debug over a wired connection? Well I want to play around with the wireless hardware some more and having a debugger would be very useful.
#92575 - wintermute - Thu Jul 13, 2006 11:37 pm
| dovoto wrote: |
| wintermute wrote: |
As it happens I'm considering just shifting to arm mode for libnds - while thumb is more size efficient and you get a hit from the 16bit ewram for arm mode the cache makes up the difference quite well. |
Can the cache hold twice as many thumb instructions as arm ? If so it seems like you might be effictivly reducing your instruction cache by a factor of two and slowing down ewram access by choosing arm over thumb. I may just be confused :) |
Well that was actually one of my original thoughts behind the whole thumb business. The cache does indeed hold twice as many thumb instructions but 4k is actually a rather large loop even for C code so, in the general case, ARM is quite a bit faster than thumb. While ARM instructions are twice as big, you can do more with a single instruction and it all seems to balance out.
I'm still undecided as yet though.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#92577 - Mighty Max - Thu Jul 13, 2006 11:42 pm
When switching from thumb to arm, the size of your compiled code doesn't double. iirc (and im not quite sure) the average factor from switching from thumb to arm was about x1.5 in my tests.
_________________
GBAMP Multiboot
#92610 - wintermute - Fri Jul 14, 2006 2:47 am
A reliable source informs me that the size ratio is around 0.6:1 and speed is 0.7:1 ( thumb:arm).
Another option I was considering was to build libnds as both thumb and arm and leave the choice up to the user but it appears that the -mthumb option only does the right thing inside the system folders.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#92647 - simonjhall - Fri Jul 14, 2006 9:51 am
| masscat wrote: |
| I was wondering why you use the Java stub and do not just connect GDB directly with the DS. |
Check out the readme :-) Ease of development was a main point, as I didn't have a debugger whilst developing it (in fact I still can't debug my own stuff as debugging a debugger with a debugger is not cool). But developing the Java side of things was much easier as I could use an existing debugger to figure out what was going on. PLUS the monster amount of console output this thing generates would just be an arse on a DS screen. I have an extra screen on my PC just so I can try and follow what's going on!
| Quote: |
| If your DS debugger stub accepts GDB Remote Serial Protocol commands then to debug over the serial port would only require changing the packet read/send functions on the DS. |
The Java part translates all the complex GDB functions to memory reads and writes, so all you gotta do (if you wanted to use my thing) is to replace the functions which get data on and off the DS. The DS contains no debugging state info (eg addresses of breakpoints or rewritten instructions).
You'd need to change the Java to use a serial interface, rather than a network socket, but the rest should be the same... I don't recommend writing your own GDB interface yourself as it's not as well documented as you'd think!
----
THUMB - I've gotta try and find some time to figure out why I can't throw an exception, but I'm kinda busy at the moment.
And debugging interrupts - are nested interrupts possible? I had a very quick test of renabling the wifi interrupts in my vblank hander, but I couldn't get that to work... (again, a very quick test).
AND! In the ARM spec it says that in IRQ mode that only r13 and r14 are banked registers. How come then in the interrupt handler r0-r12 aren't saved on entry and then restored on exit? Is there some BIOS code I've not yet seen?
#92907 - Mighty Max - Sat Jul 15, 2006 2:22 pm
| simonjhall wrote: |
AND! In the ARM spec it says that in IRQ mode that only r13 and r14 are banked registers. How come then in the interrupt handler r0-r12 aren't saved on entry and then restored on exit? Is there some BIOS code I've not yet seen? |
Yes. The bios saves the registers that can be altered but are not restored by functions (namely r0-r3 and r12).
http://www.bottledlight.com/ds/index.php/Main/Interrupts
_________________
GBAMP Multiboot
#92910 - wintermute - Sat Jul 15, 2006 2:48 pm
| bios code wrote: |
| Code: |
loc_FFFF0274
STMFD SP!, {R0-R3,R12,LR}
MRC p15, 0, R0,c9,c1
MOV R0, R0,LSR#12
MOV R0, R0,LSL#12
ADD R0, R0, #0x4000
ADR LR, loc_FFFF0290
LDR PC, [R0,#-4]
loc_FFFF0290
LDMFD SP!, {R0-R3,R12,LR}
SUBS PC, LR, #4
|
|
Another point in favour of the java gdb proxy is the caching that's been implemented there. I'd imagine things would be a bit slow otherwise - Insight appears to request data from the proxy when you hover over a variable which surprised me.
With the libnds interrupt system use REG_IME=1 at the start of your VBlank handler to allow nesting of other interrupts. You should probably do this after any code which needs to execute within the vblank period.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
#92912 - Mighty Max - Sat Jul 15, 2006 3:04 pm
| wintermute wrote: |
With the libnds interrupt system use REG_IME=1 at the start of your VBlank handler to allow nesting of other interrupts. You should probably do this after any code which needs to execute within the vblank period. |
Don't forget the I-Bit in CPSR.
_________________
GBAMP Multiboot
#92917 - wintermute - Sat Jul 15, 2006 4:09 pm
| Mighty Max wrote: |
| wintermute wrote: |
With the libnds interrupt system use REG_IME=1 at the start of your VBlank handler to allow nesting of other interrupts. You should probably do this after any code which needs to execute within the vblank period. |
Don't forget the I-Bit in CPSR. |
uh, read the code in the libnds interrupt dispatcher :P
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog
![[Images not permitted - Click here to view it]](http://img359.imageshack.us/img359/4306/dsdebugging5aj.gif){kind=link}