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
