TipsAndTricks/DebuggingBitbakeInPudb - Revision history

Bavery at 23:14, 3 February 2017

2017-02-03T23:14:31Z

← Older revision		Revision as of 23:14, 3 February 2017
Line 53:		Line 53:

	I will break in the python in the metadata and be able to stop through it and watch j=0,1,... up to 4.		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:

			[[File:Screen_Shot_2017-02-03_at_3.04.04_PM.png\|700px]]

Bavery at 22:56, 3 February 2017

2017-02-03T22:56:06Z

← Older revision		Revision as of 22:56, 3 February 2017
Line 30:		Line 30:
	This allows me to sprinkle programmatic breakpoints wherever I want.		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.		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.
			<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")
			}

			</code>
			If I then run
			<code>
			python3 -m pudb.run $(which bitbake) quilt-native
			</code>

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

Bavery at 02:43, 14 January 2017

2017-01-14T02:43:10Z

← Older revision		Revision as of 02:43, 14 January 2017
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

Bavery: 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..."

2017-01-14T02:22:59Z

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..."

New page

=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 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.

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.
You can do this for all staged binaries by setting <code>INHIBIT_SYSROOT_STRIP = "1"</code> in your local.conf

Alternatively you might want to only inhibit stripping for specific recipes, this can be achieved using recipe OVERRIDES such as:

INHIBIT_SYSROOT_STRIP_pn-swupd-server-native = "1"

I used the former as it allowed me to be certain of having all debugging symbols available.

Note: you'll need to ensure any binaries you wish to debug are (re-)staged into the sysroot after changing this setting.

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