Wireless Debugger v0.11 for DS
Here’s one homebrew application for the hardcore DS developer – DS Debugger v0.11. As the name says, the app allows developers to interactively debug their applications running on a real Nintendo DS. Created by Simon Hall, the app initialises the network, connects to the PC-side stub and installs the breakpoint-catching code. A function needs to be added to a timer or into a main update loop which polls for commands from the PC-side stub. This picks up commands to add breakpoints or read memory from the PC. Without this function, breakpoints can’t be set.
On the PC-side stub, a Java application translates the complex commands from the GNU debugger (GDB) into simple operations which the DS stub can execute. The Java stub relays messages from the DS to GDB when things like breakpoints or illegal memory accesses occur.
If you’re new to this sort of thing, you really have to go over the readme file. It’s a long read but you’d feel better after knowing how the app works. If you already know how it works and you’re just rarin’ to test the app, here’s a list of what it can 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
Of course, as this is a work in progress app, there are things it can’t do (the readme file has the complete list), but I’m pretty sure Simon is keen on releasing updates in the future.
Download: [Wireless Debugger v0.11 for DS]
Via GBA Dev
Here’s one homebrew application for the hardcore DS developer – DS Debugger v0.11. As the name says, the app allows developers to interactively debug their applications running on a real Nintendo DS. Created by Simon Hall, the app initialises the network, connects to the PC-side stub and installs the breakpoint-catching code. A function needs to be added to a timer or into a main update loop which polls for commands from the PC-side stub. This picks up commands to add breakpoints or read memory from the PC. Without this function, breakpoints can’t be set.
On the PC-side stub, a Java application translates the complex commands from the GNU debugger (GDB) into simple operations which the DS stub can execute. The Java stub relays messages from the DS to GDB when things like breakpoints or illegal memory accesses occur.
If you’re new to this sort of thing, you really have to go over the readme file. It’s a long read but you’d feel better after knowing how the app works. If you already know how it works and you’re just rarin’ to test the app, here’s a list of what it can 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
Of course, as this is a work in progress app, there are things it can’t do (the readme file has the complete list), but I’m pretty sure Simon is keen on releasing updates in the future.
Download: [Wireless Debugger v0.11 for DS]
Via GBA Dev