Re: [lttng-dev] Debugging Libaries in Babeltrace 2

[Simon Marchi via lttng-dev <lttng-dev@lists.lttng.org>]

On 10/24/23 11:52, Seidl, Aron via lttng-dev wrote:
> Hello guys,
> I’m currently a student at the company Carl Zeiss in Oberkochen Germany. I’d like to trace the Kernel from our CMM-Controller with CTF and convert it to plain text, like Babeltrace 2 does. To understand how Babeltrace 2 works with CTF, I debug the code.

Hi Aron,
:w

>  
> 
> However when I try to step into a function which is included via the extern Babeltrace 2 library (e.g. *bt_graph_run(ctx.graph)* in graph.c), the GNU Compiler steps over the function and I’m unable to look into this function.
> 
>  
> 
> I figured, it is because the Debugger cannot find the Debug Symbols even though I compile everything with Debug-Symbols and no compiler optimization.
> 
> I configure the Makefile as follows:
> 
>  
> 
> BABELTRACE_DEV_MODE=1 BABELTRACE_MINIMAL_LOG_LEVEL=TRACE BABELTRACE_DEBUG_MODE=1 CFLAGS='-g -O0' CPPFLAGS='-g -O0' LDFLAGS='-g -O0' ./configure

You probably mean CXXFLAGS, not CPPFLAGS.  CXXFLAGS are flags to be passed to the C++
compiler, CPPFLAGS are flags to be passed to the preprocessor.  It's
probably going to work anyway, since preprocessor flags are passed when
compiling, but I wanted to point it out because it looks like a mistake.

> 
>  
> 
> For test purposes, I implemented the function *bt_graph_run(NULL) *inside a new project to check, if I could step into the function with my debugger, or whether it is a general problem with my machine.
> 
> That actually worked and I was able to step into the function, but not with the normal Babeltrace 2 project.
> 
> None of my colleagues could explain this behavior, so my question now is, how do you guys debug the code? Is there a different way you debug these functions, or do I configure my project the wrong way?
> 
>  
> 
> I appreciate it if someone can help me and tell me how to configure the project so that the code is debugable.

Can you please show how you start and run babeltrace2 under GDB?

My guess is that you end up using a system version of libbabeltrace2.so
from a package you installed or something.  In GDB, do "info shared" and
see what the libbabeltrace2.so line looks like.  It should be like
this, with a path in your build directory.  There should be no asterisk
indicating that the debug info is missing.

    0x00007ffff75a87f0  0x00007ffff76f5990  Yes         /home/smarchi/build/babeltrace/src/lib/.libs/libbabeltrace2.so.0

Since we are using libtool, the src/cli/babeltrace2 file is actually a
libtool script that sets up the right environment (LD_LIBRARY_PATH and
stuff) for running the real babeltrace2 binary (found at
src/cli/.libs/babeltrace2) directly in the build tree.  The proper way
to debug it is with the libtool wrapper:

    $ libtool --mode=execute gdb -q --args src/cli/babeltrace2 /home/smarchi/src/babeltrace/tests/data/ctf-traces/1/succeed/sequence
    Reading symbols from /home/smarchi/build/babeltrace/src/cli/.libs/babeltrace2...
    (gdb) b bt_graph_run
    Function "bt_graph_run" not defined.
    Make breakpoint pending on future shared library load? (y or [n]) y
    Breakpoint 1 (bt_graph_run) pending.
    (gdb) r
    Starting program: /home/smarchi/build/babeltrace/src/cli/.libs/babeltrace2 /home/smarchi/src/babeltrace/tests/data/ctf-traces/1/succeed/sequence
    [Thread debugging using libthread_db enabled]
    Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

    Breakpoint 1, bt_graph_run (graph=0x6120000025c0) at /home/smarchi/src/babeltrace/src/lib/graph/graph.c:683
    683             BT_ASSERT_PRE_NO_ERROR();

See: https://www.gnu.org/software/libtool/manual/html_node/Debugging-executables.html

Simon
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev