Editing Documentation/Maemo 5 Developer Guide/Kernel and Debugging Guide/Maemo Debugging Guide
Warning: You are not logged in.
Your IP address will be recorded in this page's edit history.
Warning: This page is 59 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller sections.
The edit can be undone.
Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision | Your text | ||
Line 23: | Line 23: | ||
* develop software in the Linux environment using the C language | * develop software in the Linux environment using the C language | ||
* install software to the tablet device | * install software to the tablet device | ||
- | * | + | * gain root access to the device |
* install ssh to the device | * install ssh to the device | ||
* configure repositories in the <code>/etc/apt/sources.list</code> file | * configure repositories in the <code>/etc/apt/sources.list</code> file | ||
Line 33: | Line 33: | ||
To follow the debugging examples you need to have the following: | To follow the debugging examples you need to have the following: | ||
- | * | + | * Maemo SDK installed on a Linux PC |
* Nokia Internet Tablet device running [[Open development/Maemo roadmap/Fremantle|Maemo 5]]. | * Nokia Internet Tablet device running [[Open development/Maemo roadmap/Fremantle|Maemo 5]]. | ||
* USB cable to connect the device with the Linux PC | * USB cable to connect the device with the Linux PC | ||
* Internet access both for the tablet and for the Linux PC | * Internet access both for the tablet and for the Linux PC | ||
* USB networking (or WLAN) set up between the Linux PC and the device | * USB networking (or WLAN) set up between the Linux PC and the device | ||
- | * root login access to the device over | + | * root login access to the device over ssh |
- | * package | + | * package maemo-sdk-debug installed |
- | * | + | * xterm installed on the device |
- | * | + | * ssh software installed on the device |
== General Notes on Debugging == | == General Notes on Debugging == | ||
Line 49: | Line 49: | ||
When debugging the ARM architecture, pay attention to the following issues: | When debugging the ARM architecture, pay attention to the following issues: | ||
- | * To make backtraces work properly on the ARM side, the | + | * To make backtraces work properly on the ARM side, the dbg packages need to be installed for the libraries the application is using. Profiling and debugging (gdb) tools require the code to have either framepointers or debugging symbols to unwind the stack. This is necessary for showing backtraces or call graphs. |
- | * C language functions with the <code>__attribute__((__noreturn__))</code> statement need to be compiled with the gcc option: <code>-mapcs-frame</code> otherwise the compiler excludes their function frame. | + | * C language functions with the <code>__attribute__((__noreturn__))</code> statement need to be compiled with the gcc option: <code>-mapcs-frame</code> otherwise the compiler excludes their function frame. Maemo Glib and C-library noreturn functions like <code>abort()</code> already have this. Without a function frame, gdb cannot backtrace through "noreturn" functions. |
* In addition, for gdb to be able to display the correct function names during debugging, it also needs to have access to the debug symbols. Without them, gdb shows the preceding exported function name for a given address. | * In addition, for gdb to be able to display the correct function names during debugging, it also needs to have access to the debug symbols. Without them, gdb shows the preceding exported function name for a given address. | ||
Line 71: | Line 71: | ||
=== Setting up Environment === | === Setting up Environment === | ||
- | Both the Internet Tablet device, described in section [[ | + | Both the Internet Tablet device, described in section [[../../Development Environment/Maemo PC Connectivity|Maemo PC Connectivity]], and the Scratchbox environment, described in section [[../../Development Environment/Maemo SDK|Maemo SDK]], need to be set up. |
=== Preparing Scratchbox Environment for Debugging === | === Preparing Scratchbox Environment for Debugging === | ||
Line 526: | Line 526: | ||
</pre> | </pre> | ||
- | In this example, the standard | + | In this example, the standard export DEB_BUILD_OPTIONS=debug,nostrip environment variable is used, but there might be source packages that do not support these debug,nostrip options. In that case, one must make sure that the source is compiled with <code>-g</code> flag (usually this option can be added to the <code>CFLAGS</code> variable in the <code>debian/rules</code> file), and that the produced binaries will not be stripped. In the long run, it is better to modify the source package to generate a separate debug symbol (<code>-dbg</code>) package. This requires modifying both the <code>debian/rules</code> and <code>debian/control</code> files. In fact, maemopad already builds a separate debug package, but this example makes no use of it to demonstrate the simpler case. |
Line 719: | Line 719: | ||
Because the breakpoint is now cleared, you can use the application normally under <code>Xephyr</code>. | Because the breakpoint is now cleared, you can use the application normally under <code>Xephyr</code>. | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
== Debugging Hildon Desktop Plug-ins == | == Debugging Hildon Desktop Plug-ins == | ||
Line 896: | Line 890: | ||
Doing this on the device would require first disabling the software lifeguard with the flasher tool. If this is not done, the device will reboot. The flag is: | Doing this on the device would require first disabling the software lifeguard with the flasher tool. If this is not done, the device will reboot. The flag is: | ||
- | + | --set-rd-flags=no-lifeguard-reset | |
== Running Out of Memory During Debugging on the Device == | == Running Out of Memory During Debugging on the Device == | ||
Line 947: | Line 941: | ||
=== Installing Valgrind Tool === | === Installing Valgrind Tool === | ||
- | Installing Valgrind is simple. Log in | + | Installing Valgrind is simple. Log in on Scratchbox and run the following commands: |
<ol> | <ol> | ||
<li> Get Valgrind from the repository: | <li> Get Valgrind from the repository: | ||
Line 961: | Line 955: | ||
</pre> | </pre> | ||
- | |||
- | + | {{ambox|text=The maemo Valgrind version depends on the libc6-dbg. On the desktop Linux, some of the debug symbols are included in the libc6 library itself. If the debug symbols are missing from the libraries, Valgrind cannot match the error suppressions to the internal library functions. In the maemo <code>libc6</code> case, it would show lots of errors for the dynamic linker. | |
- | + | If using a non-maemo version of Valgrind, the following environment variable needs to be set before valgrinding programs using Glib: | |
- | Without this, | + | <code> |
+ | [sbox-FREMANTLE_X86: ~] > export \ | ||
+ | G_SLICE="always-malloc" | ||
+ | </code> | ||
+ | |||
+ | Without this, Valgrind will report bogus leaks from Glib.}} | ||
</li> | </li> | ||
Line 1,064: | Line 1,062: | ||
Valgrind also tells the lines in the code where these allocations that are not freed are performed. In this example, the lines in question are 48 and 26. | Valgrind also tells the lines in the code where these allocations that are not freed are performed. In this example, the lines in question are 48 and 26. | ||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
- | |||
=== Official Valgrind Manual === | === Official Valgrind Manual === | ||
Line 1,108: | Line 1,090: | ||
Debian debug packages contain ''debug symbol'' files that debuggers (like <code>gdb</code>) will automatically load when the application is debugged. | Debian debug packages contain ''debug symbol'' files that debuggers (like <code>gdb</code>) will automatically load when the application is debugged. | ||
- | + | On ARM environment, the debugger cannot do backtracing or show correct function names without debugging symbols making it thus impossible to debug optimized binaries or libraries. All libraries in the device are optimized. | |
- | In | + | In X86 target, debugging can be done without debug symbols. |
- | If the package maintainer provides no debug package, then the other developers in the community need to spend extra time and effort to recompile the application (or the library) with debugging symbols. This extra (time-consuming) step can be simply eliminated | + | If the package maintainer provides no debug package, then the other developers in the community need to spend extra time and effort to recompile the application (or the library) with the debugging symbols. This extra (time-consuming) step can be simply eliminated by the package maintainer by providing a ready compiled debug package. |
- | This section covers creating a Debian debug package from the | + | This section covers creating a Debian debug package from the <br /> maemo/Scratchbox point of view. |
It is the package maintainers role and decision to create and provide a debug package for their application or library. This means that you as the package owner are responsible to modify the debian package configurations, so that the <code>dpkg-buildpackage</code> tool will produce the additional <code>dbg</code>-package. | It is the package maintainers role and decision to create and provide a debug package for their application or library. This means that you as the package owner are responsible to modify the debian package configurations, so that the <code>dpkg-buildpackage</code> tool will produce the additional <code>dbg</code>-package. | ||
Line 1,120: | Line 1,102: | ||
If you are a maintainer of a library or binary package, it is strongly recommended to create a corresponding debug package. This is needed by anybody wanting to either debug or profile your software or something using it. | If you are a maintainer of a library or binary package, it is strongly recommended to create a corresponding debug package. This is needed by anybody wanting to either debug or profile your software or something using it. | ||
- | If the package is otherwise fine (and | + | If the package is otherwise fine (and debian/rules uses debhelper <code>dh_* scripts</code>), creating debug packages is easy, just: |
- | * Add <code>*-dbg</code> package descriptions to | + | * Add <code><nowiki>*-dbg</nowiki></code> package descriptions to debian/control file |
- | * Make sure | + | * Make sure "<code>-g</code>" is included into compiler flags and Makefiles don't strip binaries (e.g. give "<code>-s</code>" to "<code>install</code>" command) |
- | * Add "<code>--dbg-package=<package name></code>" argument to "<code>dh_strip</code>" invocation in | + | * Add "<code>--dbg-package=<package name></code>" argument to "<code>dh_strip</code>" invocation in debian/rules for each package containing binaries (<code>dh_strip</code> will then extract the debug symbols from the given binary package to a separate debug package) |
* Rebuild/test source package | * Rebuild/test source package | ||
Line 1,158: | Line 1,140: | ||
</pre> | </pre> | ||
- | If the package contains binaries instead of libraries, the <code>Section</code> should be <code>devel</code>, not <code>libdevel</code>. The new <code>-dbg</code> package may have a different name from the old style debug package (for example <code>libgtk2.0-0-dbg</code>, not <code>libgtk2.0-dbg</code>). If there are earlier (old style) debug packages in the repositories | + | If the package contains binaries instead of libraries, the <code>Section</code> should be <code>devel</code>, not <code>libdevel</code>. The new <code>-dbg</code> package may have a different name from the old style debug package (for example <code>libgtk2.0-0-dbg</code>, not <code>libgtk2.0-dbg</code>). If there are earlier (old style) debug packages in the repositories the new debug package should replace/conflict with the old one.</li> |
Line 1,172: | Line 1,154: | ||
You want to select the latter option only if you want to reveal as little of your code as possible (for example) for contract reasons. | You want to select the latter option only if you want to reveal as little of your code as possible (for example) for contract reasons. | ||
<ol><li> '''Providing all debug information in your dbg package.''' | <ol><li> '''Providing all debug information in your dbg package.''' | ||
- | + | Debian/compat levels smaller than 3 should not be used (1 is default!). If your package sets debian/compat level '''below''' 5, give the following arguments to dh_strip in debian/rules file: | |
<pre> | <pre> | ||
Line 1,199: | Line 1,181: | ||
- | If you | + | If you're using cdbs instead of debhelper (i.e. dh_* commands) in your debian/rules file, use this instead: |
<pre> | <pre> | ||
Line 1,216: | Line 1,198: | ||
<li> '''Providing just minimal debug information''' | <li> '''Providing just minimal debug information''' | ||
- | In case you do not want to reveal all information about your binary (for | + | In case you do not want to reveal all information about your binary (e.g. for contract reasons), you can provide a debug symbol file just with the <code>.debug_frame</code> section (which is the minimal information needed by <code>gdb</code> to show working backtraces in ARM environment). In addition to information provided by the binary file, it will reveal only static function names and the number of function arguments. |
+ | To do this, replace the above <code>dh_strip</code> line in <code>debian/rules</code> file <code>binary-arch</code> target with: | ||
<pre> | <pre> | ||
Line 1,226: | Line 1,209: | ||
- | Notice that the wrapper script is set executable because the <code>dpkg-source</code> does not preserve the exec permissions. Store the following wrapper script as <code>debian/wrapper/objcopy</code>: | + | Notice that the wrapper script is set executable because the <code>dpkg-source</code> does not preserve the exec permissions. |
+ | Store the following wrapper script as <code>debian/wrapper/objcopy</code>: | ||
#!/bin/sh | #!/bin/sh | ||
Line 1,241: | Line 1,225: | ||
- | With this <code>dh_strip</code> will use <code>objcopy</code> through this wrapper ( | + | With this <code>dh_strip</code> will use <code>objcopy</code> through this wrapper (i.e. remove the other debug sections).</li></ol> |
<li> Verify the package(s) | <li> Verify the package(s) | ||
Update the Debian changelog with <code>dch -i</code> and build the package with <code>dpkg-buildpackage -rfakeroot</code>. This will create new Debian source package (dsc + diff) and binary package(s) which you can install on the target for additional testing.</li> | Update the Debian changelog with <code>dch -i</code> and build the package with <code>dpkg-buildpackage -rfakeroot</code>. This will create new Debian source package (dsc + diff) and binary package(s) which you can install on the target for additional testing.</li> | ||
</ol> | </ol> | ||
See also <code>dh_strip (1)</code> and <code>debhelper (7)</code> manual pages for details about the helper scripts. | See also <code>dh_strip (1)</code> and <code>debhelper (7)</code> manual pages for details about the helper scripts. | ||
+ | |||
+ | |||
+ | {{ambox|text=If the package has any function(s) that have the <code>noreturn</code> GCC attribute, you need to make sure that the object(s) containing those are compiled with <code>-mapcs-frame</code> (or remove the noreturn attribute). This is needed for backtraces containing them to be debuggable when the binaries are optimized, the debug symbols are not enough for them. By default GCC omits frame pointer when code is optimized.}} | ||
== Using and Installing DBG Packages == | == Using and Installing DBG Packages == | ||
Line 1,269: | Line 1,256: | ||
- | + | <code>maemo-debug-scripts</code> package provides <code>native-gdb</code> script for this. | |
For gdb to find old style debug symbol files (installed directly into <code>/usr/lib/debug/</code>), use <code>LD_LIBRARY_PATH</code> or load them manually in <code>gdb</code>. | For gdb to find old style debug symbol files (installed directly into <code>/usr/lib/debug/</code>), use <code>LD_LIBRARY_PATH</code> or load them manually in <code>gdb</code>. |
Learn more about Contributing to the wiki.