1,189
edits
Changes
Jump to navigation
Jump to search
m
Robot: Cosmetic changes
Line 1:
Line 1:
==Remote Debugging with GDB==
==Remote Debugging with GDB==
−[[devkitPro]] provides gdb, the gnu debugger, which has been configured to allow remote debugging over the [[USB Gecko]]. You compile a stub of code into your wii program and run the debugger on your pc. Firstly include the code which establishes the connection:
+[[devkitPro]] provides gdb, the gnu debugger, which has been configured to allow remote debugging over the [[USB Gecko]]. You compile a stub of code into your wii program and run the debugger on your pc. Firstly include the code which establishes the connection:
#include <debug.h>
#include <debug.h>
Line 10:
Line 10:
_break();
_break();
−Your wii code must be compiled with the option -g linked with the option -ldb, included before other libraries such as -logc.
+Your wii code must be compiled with the option -g linked with the option -ldb, included before other libraries such as -logc.
−Start your wii code using normal means such as the homebrew channel. There are three debugging tools available from devkitPro which are:
+Start your wii code using normal means such as the homebrew channel. There are three debugging tools available from devkitPro which are:
* powerpc-gekko-gdb: the basic text version of gdb driven from the command line
* powerpc-gekko-gdb: the basic text version of gdb driven from the command line
* powerpc-gekko-gdbtui: a version of gdb which includes a text window showing the source code of your application
* powerpc-gekko-gdbtui: a version of gdb which includes a text window showing the source code of your application
Line 51:
Line 51:
The above examples are confirmed to work under linux but may require some modification to work under windows/msys (particularly /dev/ttyUSB0).
The above examples are confirmed to work under linux but may require some modification to work under windows/msys (particularly /dev/ttyUSB0).
−Graphical debugger options for Linux can be found on [[Devkitppc_setup_(Linux)|the linux set-up page]]
+Graphical debugger options for Linux can be found on [[Devkitppc setup (Linux)|the linux set-up page]]
−==Diagnosing crashes==
+== Diagnosing crashes ==
−When faced with a crash in your Homebrew, often you'll see a code dump with an address and some machine code. Here's my trick to track that back to a line of C++ code.
+When faced with a crash in your Homebrew, often you'll see a code dump with an address and some machine code. Here's my trick to track that back to a line of C++ code.
For example if your homebrew game crashes it might show something like this:
For example if your homebrew game crashes it might show something like this:
Line 64:
Line 64:
800084cc: ...
800084cc: ...
−The 800084ac is the memory address in hex of where the crash occurred. 809F0020 is the machine code for the offending instruction.
+The 800084ac is the memory address in hex of where the crash occurred. 809F0020 is the machine code for the offending instruction.
−===With GDB===
+=== With GDB ===
Using gdb, you can find out where the relevant code is with the command:
Using gdb, you can find out where the relevant code is with the command:
Line 81:
Line 81:
info line *0x800084ac
info line *0x800084ac
−===Alternative Method 1===
+=== Alternative Method 1 ===
A simpler way to get the line/file from an address is to use addr2line:
A simpler way to get the line/file from an address is to use addr2line:
powerpc-gekko-addr2line -e <elf file> <address>
powerpc-gekko-addr2line -e <elf file> <address>
−===Alternative Method 2===
+=== Alternative Method 2 ===
*Step 1:
*Step 1:
Line 97:
Line 97:
*Step 2:
*Step 2:
−Look at the map file that was built. The mapfile is on by default in the Wii template makefile. Typically it's in the build subdirectory and called something.map. Look in that mapfile for the nearest memory address that doesn't go over the one found in the CODE DUMP. Here is an example:
+Look at the map file that was built. The mapfile is on by default in the Wii template makefile. Typically it's in the build subdirectory and called something.map. Look in that mapfile for the nearest memory address that doesn't go over the one found in the CODE DUMP. Here is an example:
0x80008464 ShooterView::Render(BibGraphicsDevice&)
0x80008464 ShooterView::Render(BibGraphicsDevice&)
−This tells me that the crash was 72 bytes into the ShooterView::Render() function. Now to find the line number in Render()
+This tells me that the crash was 72 bytes into the ShooterView::Render() function. Now to find the line number in Render()
*Step 3:
*Step 3:
−Look at the list file for the relevant function. Here's an example:
+Look at the list file for the relevant function. Here's an example:
473 .globl _ZN11ShooterView6RenderER17BibGraphicsDevice
473 .globl _ZN11ShooterView6RenderER17BibGraphicsDevice
Line 112:
Line 112:
479 02d0 9421FF00 stwu 1,-256(1)
479 02d0 9421FF00 stwu 1,-256(1)
−The function names are mangled because this is C++ code. See http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B
+The function names are mangled because this is C++ code. See http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B
−The address of the first instruction of Render() is at 02d0. This is also line 158 in the file (".loc 1 158 0"). To find the error location, just look at 0x2d0 + 72 = 0x318. See below:
+The address of the first instruction of Render() is at 02d0. This is also line 158 in the file (".loc 1 158 0"). To find the error location, just look at 0x2d0 + 72 = 0x318. See below:
.loc 1 168 0
.loc 1 168 0
Line 120:
Line 120:
This shows machine address 0x318 has the proper machine code and the nearest .loc statement says the problem is at line 168 of the ShooterView.cpp.
This shows machine address 0x318 has the proper machine code and the nearest .loc statement says the problem is at line 168 of the ShooterView.cpp.
−For more info on the assembler output see the manual here: http://sourceware.org/binutils/docs-2.18/as/index.html
+For more info on the assembler output see the manual here: http://sourceware.org/binutils/docs-2.18/as/index.html
−===Alternative Method 3===
+=== Alternative Method 3 ===
If you are getting crashes and you dont want to hunt through assembly code, or rendered-c you can put exit(0) in parts of your code you think it might crash in - like before function calls, or variable assignments.
If you are getting crashes and you dont want to hunt through assembly code, or rendered-c you can put exit(0) in parts of your code you think it might crash in - like before function calls, or variable assignments.
Line 129:
Line 129:
It is a dirty way of finding your problem, but a lot easier to understand than the other methods shown.
It is a dirty way of finding your problem, but a lot easier to understand than the other methods shown.
+
[[Category:Development]]
[[Category:Development]]