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
 
(2 intermediate revisions by the same user not shown)
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.
= Debugging python in metadata with pudb =
Now, this is kinda out there but you can do it.
<br>
My example is definitely a tad contrived but here goes.  Suppose you want to see the state of things in the pudb debugger from a .inc file. As our example let's put the following at the top of quilt-native.inc, just after the line <code>EXTRA_OECONF = "--disable-nls"</code>:
<code>
python () {
    import sys
    from pudb import set_trace as bp
    i=5
    for j in range(i):
        print("\nCOWZ IN QUILT_NATIVE.INC\n")
        bp()
    print("\n VERSION=",sys.version,"\n")
}


I pointed gdb at our native sysroot with (from within a gsb session):
</code>
If I then run
<code>
  python3 -m pudb.run $(which bitbake) quilt-native
</code>


set sysroot /path/to/build/tmp/sysroots/x86_64-linux
I will break in the python in the metadata and be able to stop through it and watch j=0,1,... up to 4.
Looks like this:


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:
[[File:Screen_Shot_2017-02-03_at_3.04.04_PM.png|700px]]
 
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

Latest revision as of 23:14, 3 February 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.

Debugging python in metadata with pudb

Now, this is kinda out there but you can do it.
My example is definitely a tad contrived but here goes. Suppose you want to see the state of things in the pudb debugger from a .inc file. As our example let's put the following at the top of quilt-native.inc, just after the line EXTRA_OECONF = "--disable-nls": 


python () {
   import sys
   from pudb import set_trace as bp
   i=5
   for j in range(i):
       print("\nCOWZ IN QUILT_NATIVE.INC\n")
       bp()
   print("\n VERSION=",sys.version,"\n")
}

If I then run 


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

I will break in the python in the metadata and be able to stop through it and watch j=0,1,... up to 4. Looks like this:

Screen Shot 2017-02-03 at 3.04.04 PM.png

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