TipsAndTricks/DebuggingBitbakeInPudb: Difference between revisions

From Yocto Project
Jump to navigationJump to search
(Created page with "=How to debug native recipes with gdb= I recently had the need to debug a crash in a native binary that a layer I was working on invokes during the build. To debug the crash...")
 
No edit summary
Line 1: Line 1:
=How to debug native recipes with gdb=
=How to debug bitbake itself with pudb=


I recently had the need to debug a crash in a native binary that a layer I was working on invokes during the build.
I recently had the need to debug bitbake and toaster to figure out why toaster was no longer able to save event information to it's database.


To debug the crash with gdb I had to do two things; 1) have the build system generate a binary with debug symbols and 2) teach gdb where to look for files.
It turned out that I wanted to step through a number of the lib/bb/* files to see how the server was being setup.


To debug a native binary with gdb you first need to ensure that the binaries in the sysroot don't have their debugging symbols stripped.
==What I did==
You can do this for all staged binaries by setting <code>INHIBIT_SYSROOT_STRIP = "1"</code> in your local.conf
<code>
. ./poky/oe-init-build-env
. toaster start webport=0.0.0.0:8000
</code>
This set up the toaster webserver to run.


Alternatively you might want to only inhibit stripping for specific recipes, this can be achieved using recipe OVERRIDES such as:
Then my debug test:
<code>
python3 -m pudb.run $(which bitbake)  quilt-native
</code>


INHIBIT_SYSROOT_STRIP_pn-swupd-server-native = "1"
I was looking at changes to bitbake/lib/bb/main.py. So, in that file I could set up breakpoints in code like so:


I used the former as it allowed me to be certain of having all debugging symbols available.
<code>
from pudb import set_trace as bp
...
...
bp()
...
...
</code>


Note: you'll need to ensure any binaries you wish to debug are (re-)staged into the sysroot after changing this setting.
This allows me to sprinkle programmatic breakpoints wherever I want.
 
If you have a better/preferred way to step through bitbake, feel free to add/change this document.
Once you have binaries with debugging symbols you can start a gdb session and teach it where to look for files.
 
I pointed gdb at our native sysroot with (from within a gsb session):
 
set sysroot /path/to/build/tmp/sysroots/x86_64-linux
 
As native binaries can also link to host libraries, especially libc, I also told gdb to look in both the sysroot and the host for shared libraries:
 
set solib-search-path /path/to/build/tmp/sysroots/x86_64-linux/usr/lib:/usr/lib64/:/lib
 
With those commands run I was ready to operate gbd as usual and quickly narrowed down the cause of the crash.
 
For more information on the gdb commands above see the gdb manual section [https://sourceware.org/gdb/current/onlinedocs/gdb/Files.html#Files "Commands to Specify Files"]
 
= To Do =
 
* Verify whether solib-search-path should include sysroot and host paths, or just *add* host paths.
* test it still works

Revision as of 02:43, 14 January 2017

How to debug bitbake itself with pudb

I recently had the need to debug bitbake and toaster to figure out why toaster was no longer able to save event information to it's database.

It turned out that I wanted to step through a number of the lib/bb/* files to see how the server was being setup.

What I did


. ./poky/oe-init-build-env
. toaster start webport=0.0.0.0:8000

This set up the toaster webserver to run.

Then my debug test: 


python3 -m pudb.run $(which bitbake)  quilt-native

I was looking at changes to bitbake/lib/bb/main.py. So, in that file I could set up breakpoints in code like so: 


from pudb import set_trace as bp
...
...
bp()
...
...

This allows me to sprinkle programmatic breakpoints wherever I want. If you have a better/preferred way to step through bitbake, feel free to add/change this document.

Retrieved from "https://wiki.yoctoproject.org/wiki/index.php?title=TipsAndTricks/DebuggingBitbakeInPudb&oldid=22773"