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 17: Line 17:
* [[Documentation/devtools/maemo5/gdb|gdb]] - The Gnu Project Debugger. General tool for various debugging needs.
* [[Documentation/devtools/maemo5/gdb|gdb]] - The Gnu Project Debugger. General tool for various debugging needs.
-
* [[Documentation/devtools/maemo5/valgrind|valgrind]] - Debugger and profiler. Valgrind works only in the X86 environment under Scratchbox, so this tool cannot be used on the device itself.
+
* [[Documentation/devtools/maemo5/valgrind|valgrind]] - Debugger and profiler. Valgrind works only in the X86 environment under Scratchbox, so this tool cannot be used in the device itself.
This section assumes that the developer already knows how to:
This section assumes that the developer already knows how to:
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
-
* [[root access|gain root access]] to the 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 /etc/apt/sources.list file
* set up USB networking between a Linux PC and the Tablet (the device can also be used over a local WLAN connection instead)
* set up USB networking between a Linux PC and the Tablet (the device can also be used over a local WLAN connection instead)
* work with the Scratchbox environment and Scratchbox targets
* work with the Scratchbox environment and Scratchbox targets
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:
-
* [[Documentation/Maemo_5_Final_SDK_Installation|Maemo SDK installed on a Linux PC]]
+
* Maemo SDK installed in a Linux PC
-
* Nokia Internet Tablet device running [[Open development/Maemo roadmap/Fremantle|Maemo 5]].
+
* Nokia Internet Tablet device running OS 2009.
* 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 [[SSH]]
+
* root login access to the device over ssh
-
* package <code>maemo-sdk-debug</code> installed
+
* package maemo-sdk-debug installed
-
* [[terminal|xterm]] installed on the device
+
* xterm installed in the device
-
* SSH software installed on the device
+
* ssh software installed in 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 debug 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.
+
* 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 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. On Maemo, the Glib and C library noreturn functions like <code>abort()</code> already have this. Without a function frame, gdb cannot backtrace through "noreturn" functions.
+
* 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 the 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.
=== Debugging Issues in Scratchbox ===
=== Debugging Issues in Scratchbox ===
-
It is recommended to use the native gdb in the target, not the Scratchbox host gdb.
+
It is recommended to use the native gdb in the target, not the Scratchbox host-gdb.
When debugging threads in an application, gdb needs to be linked against the same thread library that the application is using. For this reason, the gdb provided in Scratchbox is not suitable for threads debugging, and the native gdb must be used instead. If you see errors such as:
When debugging threads in an application, gdb needs to be linked against the same thread library that the application is using. For this reason, the gdb provided in Scratchbox is not suitable for threads debugging, and the native gdb must be used instead. If you see errors such as:
Line 71: Line 71:
=== Setting up Environment ===
=== Setting up Environment ===
-
Both the Internet Tablet device, described in section [[Documentation/Maemo PC Connectivity Tutorial|Maemo PC Connectivity]], and the Scratchbox environment, described in section [[../../Development Environment/Maemo SDK|Maemo SDK]], need to be set up.
+
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 ===
-
If Maemo SDK is not yet installed, it must be installed before continuing. After [[Documentation/Maemo 5 Final SDK Installation|installing the Maemo SDK]], the default target names are FREMANTLE_ARMEL and FREMANTLE_X86. These are the names used in this example.
+
If Maemo SDK is not yet installed, it must be installed before continuing. After [[Documentation/Maemo 5 Final SDK Installation|installing Maemo SDK]], the default target names are FREMANTLE_ARMEL and FREMANTLE_X86. These are the names used in this example.
Scratchbox provides a version of gdb, which is used when executing <code>gdb</code>. It is also possible to use the host system (non-Scratchbox) version of gdb, by executing <code>native-gdb</code>.
Scratchbox provides a version of gdb, which is used when executing <code>gdb</code>. It is also possible to use the host system (non-Scratchbox) version of gdb, by executing <code>native-gdb</code>.
Line 143: Line 143:
# Disable the SDK repository by removing or commenting out the lines from your  <code>/etc/apt/sources.list</code> file
# Disable the SDK repository by removing or commenting out the lines from your  <code>/etc/apt/sources.list</code> file
-
You should now have gdb and gdbserver (included in the gdb package) installed to the device.
+
You should now have the gdb and gdbserver (included in the gdb package) installed in the device.
=== Debugging Use Cases with Gdb ===
=== Debugging Use Cases with Gdb ===
Line 171: Line 171:
-
<li>Next, start gdb with the <code>gdb_example</code> application as a parameter.
+
<li>Next, start the gdb with the <code>gdb_example</code> application as a parameter.
<pre>
<pre>
Line 211: Line 211:
</ol>
</ol>
-
The above shows that the running of the application stopped in function <code>example_3</code>. This happened because the breakpoint (<code>br example_3</code>) was set. Note that the line numbers in the examples may vary if there have been changes to the example sources.
+
The above shows that the running of the application stopped in function <code>example_3</code>. This happened, because the breakpoint (<code>br example_3</code>) was set.
 +
 
 +
{{ambox|text=N.B. the line numbers in the examples may vary if there have been changes to the example sources.}}
Now the backtrace (bt) can be listed from application to see what functions have been called. The list goes from recent to older. The oldest function was naturally the <code>main()</code> function at the end of the list. It shows also the parameters to the called functions.
Now the backtrace (bt) can be listed from application to see what functions have been called. The list goes from recent to older. The oldest function was naturally the <code>main()</code> function at the end of the list. It shows also the parameters to the called functions.
Line 265: Line 267:
==== Debugging Command Line Application in Internet Tablet Device ====
==== Debugging Command Line Application in Internet Tablet Device ====
-
It is possible to debug an application in the Internet tablet device itself using gdb. Before starting, log in to the device and install (if you have not done so yet) the gdb debugger to the device:
+
It is possible to debug an application in the Internet tablet device itself using gdb. Before starting, log in on the device and install (if you have not done so yet) the gdb debugger to the device:
   
   
  /home/user # apt-get install gdb
  /home/user # apt-get install gdb
Line 366: Line 368:
-
<li> The <code>gdb_example2</code> is now running in the background, and it starts to dump its output to the screen. There are some <code>sleep()</code> calls in <code>gdb_example2</code>, so that you have time to kill it with the SIGSEGV signal. Now just make it to generate a core dump. Assuming that the process is referred to as %1, use the kill command as below and press the ENTER key a couple of times:
+
<li> The <code>gdb_example2</code> is now running in the background, and it starts to dump its output to the screen. There are some <code>sleep()</code> calls in the <code>gdb_example2</code>, so that you have time to kill it with the SIGSEGV signal. Now just make it to generate a core dump. Assuming that the process is referred to as %1, use the kill command as below and press the ENTER key a couple of times:
<pre>  
<pre>  
Line 384: Line 386:
-
<li> Extract the compressed data before you can use it with gdb. Install the sp-rich-core-postproc package and run the extract command which creates a new directory (given as a second parameter) where to extract data:
+
<li> Extract the compressed data before you can use it with gdb. Install sp-rich-core-postproc package and run the extract command which creates a new directory (given as a second parameter) where to extract data:
<pre>  
<pre>  
Line 396: Line 398:
-
<li> The <code>gdb_example2</code> is linked against the <code>libc</code> library. If you want to be able to resolve symbols also for the library during debugging, install <code>libc6-dbg</code> package in the device. ''The same rule applies to other libraries that your application might be linked against.''  See the further notes about the DBG packages in this material. Now install the <code>libc6-dbg</code> package to get symbols for the library.
+
<li> The <code>gdb_example2</code> is linked against the <code>libc</code> library. If you want to be able to resolve symbols also for the library during debugging, install <code>libc6-dbg</code> package in the device. ''The same rule applies to other libraries that your application might be linked against.''  See the further notes about the DBG packages in this material.
 +
Now install the <code>libc6-dbg</code> package to get symbols for the library.
Line 412: Line 415:
-
<li> Now you can debug the core file together with the <code>gdb_example2</code> binary that you compiled with the -g flag. Try and see where the execution of the <code>gdb_example2</code> was when you used the <code>-SIGSEGV</code> signal. Start gdb and give <code>gdb_example2</code> as the first parameter, and the core file as the second parameter:
+
<li> Now you can debug the core file together with the <code>gdb_example2</code> binary that you compiled with the -g flag. Try and see where the execution of the <code>gdb_example2</code> was when you used the <code>-SIGSEGV</code> signal. Start the gdb and give the <code>gdb_example2</code> as the first parameter, and the core file as the second parameter:
<pre>
<pre>
Line 441: Line 444:
-
The example above shows that now gdb is using debug symbols from <code>/usr/lib/debug/lib/libc-2.5.so</code>. Had the libc6-dbg package not been installed, gdb would not have information available about the libraries' debug symbols. Now, gdb is waiting for a command, so just give the bt (backtrace) command. You should see something similar to this:
+
The example above shows that now gdb is using debug symbols from <code>/usr/lib/debug/lib/libc-2.5.so</code>. Had the libc6-dbg package not been installed, the gdb would not have information available about the libraries' debug symbols.
 +
Now, the gdb is waiting for a command, so just give the bt (backtrace) command. You should see something similar to this:
Line 453: Line 457:
-
Note that for this simple example, the available <code>libc6-dbg</code> package was installed before starting to debug the <code>gdb_example2</code> application. Backtraces work only if debug packages are installed also for the libraries through which the backtrace goes.
+
{{ambox|text=For this simple example, the available <code>libc6-dbg</code> package was installed before starting to debug the <code>gdb_example2</code> application. Backtraces work only if debug packages are installed also for the libraries through which the backtrace goes.}}
Line 464: Line 468:
Because the binaries and libraries in the device are prelinked, successful debugging inside the Scratchbox environment using the programs core file (from the device) would require that:
Because the binaries and libraries in the device are prelinked, successful debugging inside the Scratchbox environment using the programs core file (from the device) would require that:
-
* you copy the relevant libraries (the ones that the application is using) from the device to Scratchbox. Otherwise, addresses in the prelinked and unprelinked libraries would not match, and gdb backtraces would not load the library.
+
* you copy the relevant libraries (i.e. the ones the application is using) from the device to the Scratchbox. Otherwise addresses in the prelinked and unprelinked libraries would not match, and gdb backtraces would not load the library.
* If the core file debugging is performed in the Scratchbox ARMEL environment, the native gdb program needs to be used instead of the one provided by Scratchbox. See the previous section on how to set the native gdb as the default one.
* If the core file debugging is performed in the Scratchbox ARMEL environment, the native gdb program needs to be used instead of the one provided by Scratchbox. See the previous section on how to set the native gdb as the default one.
-
After copying the <code>/lib/libc6</code> library from the device and setting the native gdb to be used, the application can be debugged normally. Keep in mind that generally the Scratchbox tools override the target tools.
+
After copying the <code>/lib/libc6</code> library from the device and setting the native gdb to be used, the application can be debugged normally.
 +
 
 +
 
 +
{{ambox|text=Keep in mind that generally the Scratchbox tools override the target tools.}}
Line 475: Line 482:
Many maemo applications use the graphical UI, and debugging these applications differs slightly from debugging simple command line applications.
Many maemo applications use the graphical UI, and debugging these applications differs slightly from debugging simple command line applications.
-
Here maemopad will be used as an example application to debug in the X86 target with gdb.
+
Here the maemopad will be used as an example application to debug in the X86 target with gdb.
-
If the Scratchbox environment is set up correctly as explained above, these steps should be easy to follow to perform UI debugging with the maemopad application.
+
If the Scratchbox environment is set up correctly as explained above, these steps should be easy to follow to perform UI debugging with maemopad application.
<ol>
<ol>
-
<li> Activate the X86 target, go to the testing directory and download the source package of maemopad.
+
<li> Activate the X86 target, go to the testing directory and download the source package of maemopad application.
Line 526: Line 533:
</pre>
</pre>
-
In this example, the standard <code>export DEB_BUILD_OPTIONS=debug,nostrip</code> 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.
+
 
 +
{{ambox|text=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 577: Line 585:
</pre>
</pre>
-
You should now have the application framework up and running and the <code>Xephyr</code> window should contain the SDK UI.</li>
+
You should now have the application framework up and running and the <code>Xephyr</code> window should contain the normal SDK UI.</li>
Line 614: Line 622:
-
<li> Start the maemopad application from <code>gdb</code>.
+
<li> Start the maemopad application from the <code>gdb</code>.
<pre>  
<pre>  
Line 623: Line 631:
-
Note that for thread-debugging the native gdb program is used. If you need to debug threads in the application, you need to use the native gdb linked against the same thread library that your application is using. Remember that the Scratchbox <code>gdb</code> is not suitable for this purpose. To use the native <code>gdb</code>, <code>native-gdb</code> needs to be used, as mentioned earlier in this material.
+
{{ambox|text=Thread-debugging: Now the native gdb program is used. If you need to debug threads in the application, you need to use the native gdb linked against the same thread library that your application is using. Remember that the Scratchbox <code>gdb</code> is not suitable for this purpose. To use the native <code>gdb</code>, <code>native-gdb</code> needs to be used, as mentioned earlier in this material.}}
</li>
</li>
Line 636: Line 644:
-
<li> The breakpoint that you set above is now reached, and execution of maemopad is stopped. The debugger waits for your command now. Try something simple, like using the list command to see where the execution of the application is going. You should get:
+
<li> The breakpoint that you set above is now reached, and execution of maemopad application is stopped. The gdb debugger waits for your command now. Try something simple, like using the list command to see where the execution of the application is going. You should get:
<pre>
<pre>
Line 653: Line 661:
-
<li> You can now debug maemopad normally. Try and see, if you can execute the maemopad step by step so that you can get the new writing area on screen. Enter the s command like this:
+
<li> You can now debug the maemopad normally. Try and see, if you can execute the maemopad step by step so that you can get the new writing area on screen. Enter the s command like this:
<pre>
<pre>
Line 690: Line 698:
-
<li> If you now continued debugging with the <code>s</code> (step) command, you would end up looping the gtk main event loop. However, it is better to just give the <code>c</code> (continue) command:
+
<li> If you now continued debugging with <code>s</code> (step) command, you would end up looping the gtk main event loop. However, it is better to just give the <code>c</code> (continue) command:
<pre>  
<pre>  
Line 718: Line 726:
</ol>
</ol>
-
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 the <code>Xephyr</code>.
-
 
+
-
===== Alternative method for starting gdb =====
+
-
 
+
-
Rather than starting the application framework, followed by gdb, it is possible to do both at the same time by passing an extra argument to the <code>af-sb-init.sh</code> script. For example:
+
-
af-sb-init.sh start --gdb=my_app
+
-
where <code>my_app</code> is the application to debug.
+
== Debugging Hildon Desktop Plug-ins ==
== Debugging Hildon Desktop Plug-ins ==
Line 790: Line 792:
-
<li> Install the newly-compiled debug version of the package hello-world-app_2.2_i386.deb:
+
<li> Install the newly compiled debug version of the package hello-world-app_2.2_i386.deb:
<pre>
<pre>
Line 812: Line 814:
==== Attaching to Maemo-Launched Application with Gdb ====
==== Attaching to Maemo-Launched Application with Gdb ====
-
With maemo-launched applications, it is necessary to give the maemo-launcher binary to <code>gdb</code> and attach to the already running process.
+
With maemo-launched applications, it is necessary to give maemo-launcher binary to <code>gdb</code> and attach to the already running process.
  [sbox-FREMANTLE_X86: ~/ ] > export DISPLAY=:2
  [sbox-FREMANTLE_X86: ~/ ] > export DISPLAY=:2
Line 878: Line 880:
-
The backtrace shows which functions were called before the breakpoint was reached at <code>hello_world_dialog_show()</code>. Now the plug-in can be debugged normally with gdb.
+
The backtrace tells what functions were called before the breakpoint was reached at <code>hello_world_dialog_show()</code>. Now the plug-in can be debugged normally with gdb.
Because the hello world plug-in was compiled with the <code>-g</code> option, the source code listing can be viewed with the <code>list</code> command.
Because the hello world plug-in was compiled with the <code>-g</code> option, the source code listing can be viewed with the <code>list</code> command.
Line 894: Line 896:
-
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:
+
{{ambox|text=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
+
<code>--set-rd-flags=no-lifeguard-reset</code>}}
-
== Running Out of Memory During Debugging on the Device ==
+
== Running Out of Memory During Debugging in Device ==
If running out of RAM during debugging on the device, there are a couple of options:
If running out of RAM during debugging on the device, there are a couple of options:
Line 909: Line 911:
</pre>
</pre>
-
By default, processes have an OOM (out-of-memory) adjustment value of zero. The value <code>-17</code> disables the kernel OOM killing for the given process. '''N.B.'''  As a result of this, some other processes might be killed by the kernel.</li>
+
By default, processes have OOM (out-of-memory) adjustment value of zero. The value <code>-17</code> disables the kernel OOM killing for the given process. '''N.B.'''  As a result of this, some other processes might be killed by the kernel.</li>
Line 919: Line 921:
<code>gdbserver</code> is a debugging tool that can be started and run in the Internet Tablet device. Then a connection can be made to this running instance of gdbserver program from a Linux PC with a gdb program. Gdbserver uses a lot less memory than a full scale gdb program, thus making it possible to perform debugging in devices that have limited RAM, such as PDAs.
<code>gdbserver</code> is a debugging tool that can be started and run in the Internet Tablet device. Then a connection can be made to this running instance of gdbserver program from a Linux PC with a gdb program. Gdbserver uses a lot less memory than a full scale gdb program, thus making it possible to perform debugging in devices that have limited RAM, such as PDAs.
-
The gdbserver does not care about symbols in the binary, but instead the Linux PC side gdb expects to have a local copy of the binary being debugged so that the binaries in the device can be stripped. Debugging core files from the device in Scratchbox with <code>gdbserver</code> has the same issues. In practice, it is easier to perform the debugging in the device itself. See the section above about prelinked binaries and libraries.
+
The gdbserver does not care about symbols in the binary, but instead the Linux PC side gdb expects to have a local copy of the binary being debugged so that the binaries in the device can be stripped.
 +
 
 +
 
 +
{{ambox|text=Debugging core files from the device in Scratchbox with <code>gdbserver</code> has the same issues. In practice, it is easier to perform the debugging in the device itself. See the section above about prelinked binaries and libraries.}}
Line 947: Line 952:
=== Installing Valgrind Tool ===
=== Installing Valgrind Tool ===
-
Installing Valgrind is simple. Log in to Scratchbox and run the following commands:
+
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 966:
</pre>  
</pre>  
-
The Maemo version of valgrind depends on the <code>libc6-dbg</code> package. On 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:
+
{{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:
-
[sbox-FREMANTLE_X86: ~] > export G_SLICE="always-malloc"
+
<code>
 +
[sbox-FREMANTLE_X86: ~] > export \
 +
G_SLICE="always-malloc"
 +
</code>
-
Without this, valgrind will report bogus leaks from Glib. The GNOME wiki has [http://live.gnome.org/Valgrind more information on the use of valgrind with Glib].
+
Without this, Valgrind will report bogus leaks from Glib.}}
</li>
</li>
Line 1,064: Line 1,073:
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.
-
 
-
==== Alternative method for starting Valgrind ====
 
-
 
-
[[#Alternative method for starting gdb|As with gdb]], Valgrind can be started together with the application framework, which is especially useful for graphical applications that must normally be run with <code>run-standalone.sh</code>. For example, to start the application framework an an application <code>my_app</code> underValgrind:
 
-
af-sb-init.sh start --valgrind=my_app
 
-
If other Valgrind frontends are required, they can be set with the environment variables:
 
-
* <code>VALGRINDCMD</code>: the command you want to run inside valgrind
 
-
* <code>VALGRIND</code>: the valgrind command and parameters, including the frontend to use
 
-
For example, to run <code>massif</code> on <code>maemo-af-desktop</code>:
 
-
VALGRINDCMD="maemo-af-desktop" VALGRIND="valgrind --tool=massif --num-callers=50 \
 
-
        --trace-children=yes --depth=5 --format=html -log-file=/tmp/massif \
 
-
        --alloc-fn=g_malloc --alloc-fn=g_malloc0 --alloc-fn=g_realloc \
 
-
        --alloc-fn=g_slice_alloc --alloc-fn=g_try_malloc \
 
-
        --alloc-fn=g_slice_alloc0" af-sb-init.sh start
 
-
...
 
-
af-sb-init.sh stop
 
=== Official Valgrind Manual ===
=== Official Valgrind Manual ===
Line 1,108: Line 1,101:
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.
-
In an ARM environment, the debugger cannot do backtracing or show correct function names without debugging symbols, making it impossible to debug optimized binaries or libraries. All libraries in the device are optimized.
+
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 an X86 target, debugging can be done without debug symbols.
+
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 a ready-compiled debug package.
+
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 Maemo/Scratchbox point of view.
+
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,113:
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 <code>debian/rules</code> uses debhelper <code>dh_* scripts</code>), creating debug packages is easy, just:
+
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 the <code>debian/control</code> file
+
* Add <code><nowiki>*-dbg</nowiki></code> package descriptions to debian/control file
-
* Make sure that "<code>-g</code>" is included in the compiler flags and Makefiles do not strip binaries (for example, give "<code>-s</code>" to "<code>install</code>" command)
+
* 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=&lt;package name&gt;</code>" argument to "<code>dh_strip</code>" invocation in <code>debian/rules</code> 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)
+
* Add "<code>--dbg-package=&lt;package name&gt;</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,151:
</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, the new debug package should replace or conflict with the old one.</li>
+
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,165:
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.'''  
-
<code>debian/compat</code> levels smaller than 3 should not be used (1 is default!). If your package sets <code>debian/compat</code> level '''below'''  5, give the following arguments to dh_strip in <code>debian/rules</code>:
+
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,192:
-
If you are using cdbs instead of debhelper in your <code>debian/rules</code> file, use this instead:
+
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,209:
<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 contractual reasons, as an example), 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 an 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:
+
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,220:
-
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,236:
-
With this <code>dh_strip</code> will use <code>objcopy</code> through this wrapper (and remove the other debug sections).</li></ol>
+
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,267:
-
The <code>maemo-debug-scripts</code> package provides <code>native-gdb</code> script for this.
+
<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.


Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!


Cancel | Editing help (opens in new window)

Templates used on this page: