How to configure a debug build


We are trying to use Lauterbach with TX1 and need to make a debug build.
Would you please share the information of how to configue a debug build?

Is there a way to know whether the image we build is a debug build or not?

Should we set CONFIG_DEBUG_INFO?
(but in TX1 tegra21_defconfig, CONFIG_DEBUG_INFO=y)


hello linuxsky,

if you want more kernel message from debug build, had you tried to change the console log level as below ?

$ sudo dmesg -n 5

I have not yet been able to properly attach the trace32, but in theory more debug info does not hurt. So far as I know the CONFIG_DEBUG_INFO should be configured. It looks like on R24.2.1 required configs are probably already in place, but you’d still need the vmlinux version of the kernel so you might use the existing “/proc/config.gz” to build a new kernel with the exact same config.

hello linuxsky,

could you try to add below build flavor setting in the step 2 of the Setting Up the Lauterbach Debugging Scripts Environment

$ export BUILD_FLAVOR=debug

hello linuxsky,

could you please confirm the build flavor settings in comment #4 works for you.

I actually just recently got this to work. I ended up making some detailed notes in a spreadsheet (this was for R24.2.1). If you message me with an email I can send you a copy tomorrow.

Just finished a spreadsheet of Trace32 notes. Once the spam software scans it should show up here.

Changed the attached zip, it had the wrong file in the zip. This zip should be correct. (54.7 KB)

thanks for the valuable input, linuxdev.

however, the attachment in comment #6 seems not complete.
could you please check the content, thanks

I’m not on my development machine right now, I’ll have to check tomorrow. From this machine it seems my spreadsheet is not unpacking/loading correctly (at least not the version downloaded through my above post…I’ll have to find out if the spreadsheet was somehow truncated, or if my other machine’s version of LibreOffice is just failing).

Spreadsheet comment 6 was intended to save my sanity when trying to keep an archive of multiple builds using multiple compilers (I have way too many cross compilers and several kernels for each compiler).

Assuming “/home/t32/” is synonymous with “”…

There is a script line wanting the uncompressed vmlinux kernel file, and names the “” directory as part of a full path (see: export KERNEL_ELF="/home/t32/vmlinux"). When actually running the Lauterbach software it apparently changes its working directory to “/bin/pc_linux64/”, the previous full path has the prefix thrown away, and so a second vmlinux file is needed in the new working directory. I created a symbolic link at “/bin/pc_linux64/vmlinux” which points at “/vmlinux”…that link, “/vmlinux” is itself a link to a directory containing multiple build configurations (those are the hard link real files). For me, this is at “/images//vmlinux-$(uname -r)”. All files of interest for preserving are placed there.

Example: Using Crosstool-ng-4.8.2, these real files exist:

<t32>/images/3.10.96-debug1_crosstool-ng-4.8.2/modules/...output of "make modules install.."
# make modules install has for example:

When I want to debug with that kernel those files are what I’ve actually booted to on the JTX1, and symbolic link “/vmlinux” points at:


Basically during kernel build module destination was “/images/3.10.96-debug1_crosstool-ng-4.8.2/modules/”. Changing just one vmlinux link keeps naming generic and my archive of various builds never needs to be touched or copied.

The overall work flow I use is build a new kernel, install with “uname -r” uniqueness, and basically copy the installed files to somewhere in “/images/”. Then I just change “/vmlinux” symbolic link to point at the correct “images” directory vmlinux (the same as the one booted on the JTX1).


<t32>/vmlinux # symbolic link.
<t32>/images/...somewhere.../vmlinux-uname-convention # what sym link above points to.
<t32>/bin/pc_linux64/vmlinux # symbolic link points at <t32>/vmlinux

All files distributed under the L4T documentation “baggage” for Lauterbach are unpacked in their respective L4T version directory, and a symbolic link added to all of them in “/bin/pc_linux64”. There isn’t much need to change those often, they should work for quite some time once edited. However, having them placed by symbolic link instead of hard file copy makes it obvious the files were not distributed with Lauterbach’s own install files (one can easily delete all of the sym links with “find -type l” and they won’t get mixed together).

If you get an error with that let me know, I’ll figure out what part of my environment let it work for me and add it to the spreadsheet. I always start in “/home/t32/”, so it is possible if you start the application from elsewhere finding vmlinux might break.

Dear Jerry Chang and Linuxdev,

Thank you for your support.
I will try your data as I get the Trace32 back.
We did get Trace32 work without changing the original compiling steps.
We did use R24.2.1 of Lauterbach Debugging Scripts.

Thank you,