wraggster
July 12th, 2006, 19:24
simonjhall (http://forum.gbadev.org/viewtopic.php?t=10332) has released a wireless debugger for the Nintendo DS, heres the info:
This is a wireless debugger for the Nintendo DS. It allows homebrew developers to interactively debug their applications running on a real Nintendo DS.
Things it can currently do:
- suspend the program at user-defined breakpoints
- step individual instructions, assuming the program has paused at a breakpoint
- step whole lines of source code
- inspect memory locations - and assuming a symbol table is present in the original ELF - variables and other structures can be read and their values can be changed
- inspect the state of all registers in the user ARM execution mode - including the program counter, link register, stack pointer and status register
- evaluate all types of ARM branch and condition instructions, allowing you to follow the execution of code properly in most circumstances
- it has a blacklist function, which defines which functions shouldn't be stepped into (when a b/bl/bx instruction is encountered). This is useful to prevent the debugger from stepping inside itself, or functions used by the debugger. If you do step into the debugger, it will probably get into an endless loop and hang.
- it can break on invalid memory access, signalling a SIGBUS message to the host debugger
- it can break when an invalid instruction is executed - this signals a SIGILL message to the host debugger
- both these exceptions destroy the original instruction in memory, so if you read the original opcode back from DS memory you'll get the breakpoint stub opcode instead. To get the real opcode, disassemble the ELF instead. If there's demand for having the real opcode left in memory I'll make the changes required to fix this.
- with minimal work, it ought to be able to co-exist with applications which use sgstair's wireless library
Download and Give Feedback Via Comments
This is a wireless debugger for the Nintendo DS. It allows homebrew developers to interactively debug their applications running on a real Nintendo DS.
Things it can currently do:
- suspend the program at user-defined breakpoints
- step individual instructions, assuming the program has paused at a breakpoint
- step whole lines of source code
- inspect memory locations - and assuming a symbol table is present in the original ELF - variables and other structures can be read and their values can be changed
- inspect the state of all registers in the user ARM execution mode - including the program counter, link register, stack pointer and status register
- evaluate all types of ARM branch and condition instructions, allowing you to follow the execution of code properly in most circumstances
- it has a blacklist function, which defines which functions shouldn't be stepped into (when a b/bl/bx instruction is encountered). This is useful to prevent the debugger from stepping inside itself, or functions used by the debugger. If you do step into the debugger, it will probably get into an endless loop and hang.
- it can break on invalid memory access, signalling a SIGBUS message to the host debugger
- it can break when an invalid instruction is executed - this signals a SIGILL message to the host debugger
- both these exceptions destroy the original instruction in memory, so if you read the original opcode back from DS memory you'll get the breakpoint stub opcode instead. To get the real opcode, disassemble the ELF instead. If there's demand for having the real opcode left in memory I'll make the changes required to fix this.
- with minimal work, it ought to be able to co-exist with applications which use sgstair's wireless library
Download and Give Feedback Via Comments