[lttng-dev] Debugging Libaries in Babeltrace 2

[lttng-dev] Debugging Libaries in Babeltrace 2

[Seidl, Aron via lttng-dev]

[-- Attachment #1.1: Type: text/plain, Size: 2042 bytes --]

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.

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

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.

Sincerely,
Aron

__________
Aron Seidl
DH-Student IT Education

Carl Zeiss AG
Carl-Zeiss-Strasse 22
73447 Oberkochen, Deutschland

aron.seidl@zeiss.com<mailto:aron.seidl@zeiss.com>
www.zeiss.de<http://www.zeiss.de/>
__________
Carl Zeiss AG
Sitz der Gesellschaft: Oberkochen, Deutschland
Vorsitzender des Aufsichtsrates: Dr. Michael Bolle
Vorstand: Dr. Karl Lamprecht (Vorsitzender),
Susan-Stefanie Breitkopf, Sven Hermann, Dr. Christian Müller,
Andreas Pecher, Dr. Jochen Peter, Dr. Markus Weber
Amtsgericht Ulm, HRB 501 555, USt-IdNr: DE 811 119 940



[-- Attachment #1.2: Type: text/html, Size: 8890 bytes --]

[-- Attachment #2: Type: text/plain, Size: 156 bytes --]

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

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

[Simon Marchi via lttng-dev]

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

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

[Seidl, Aron via lttng-dev]

Hi Simon,
Thanks for your quick answer!
I run GDB like this:
gdb --args ./babeltrace2 /home/aron/Schreibtisch/kernel4 -o text
(I'm in src/cli/.libs)

I don't think I've ever installed a System Version of babeltrace2, so it is really weird that GDB uses following library:

0x00007ffff7f36f00  0x00007ffff7f89749  Yes (*)     /lib/x86_64-linux-gnu/libbabeltrace2.so.0
(*): Shared library is missing debugging information.

And you're absolutely right! That is the reason why I can't debug it.
Is there a way to specify the library path? Because even with the libtool wrapper, GDB uses the release version of libbabeltrace2.so.0.

You're helping me a lot, thank you! :)
I hope you have a great day!

Kind regards,
Aron
__________
Aron Seidl
DH-Student IT Education

Carl Zeiss AG
Carl-Zeiss-Strasse 22
73447 Oberkochen, Deutschland

aron.seidl@zeiss.com
http://www.zeiss.de/
__________
Carl Zeiss AG
Sitz der Gesellschaft: Oberkochen, Deutschland
Vorsitzender des Aufsichtsrates: Dr. Michael Bolle
Vorstand: Dr. Karl Lamprecht (Vorsitzender),
Susan-Stefanie Breitkopf, Sven Hermann, Dr. Christian Müller,
Andreas Pecher, Dr. Jochen Peter, Dr. Markus Weber
Amtsgericht Ulm, HRB 501 555, USt-IdNr: DE 811 119 940




-----Ursprüngliche Nachricht-----
Von: Simon Marchi <simark@simark.ca>
Gesendet: Dienstag, 24. Oktober 2023 20:52
An: Seidl, Aron <aron.seidl@zeiss.com>; lttng-dev@lists.lttng.org
Betreff: Re: [lttng-dev] Debugging Libaries in Babeltrace 2

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

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

[Philippe Proulx via lttng-dev]

On Wed, Oct 25, 2023 at 3:29 AM Seidl, Aron via lttng-dev
<lttng-dev@lists.lttng.org> wrote:
>
> Hi Simon,
> Thanks for your quick answer!
> I run GDB like this:
> gdb --args ./babeltrace2 /home/aron/Schreibtisch/kernel4 -o text
> (I'm in src/cli/.libs)
>
> I don't think I've ever installed a System Version of babeltrace2, so it is really weird that GDB uses following library:
>
> 0x00007ffff7f36f00  0x00007ffff7f89749  Yes (*)     /lib/x86_64-linux-gnu/libbabeltrace2.so.0
> (*): Shared library is missing debugging information.
>
> And you're absolutely right! That is the reason why I can't debug it.

Note that you can also install the project locally:

    $ BABELTRACE_DEV_MODE=1 BABELTRACE_MINIMAL_LOG_LEVEL=TRACE \
      BABELTRACE_DEBUG_MODE=1 CFLAGS='-g -O0' CPPFLAGS='-g -O0' \
      ./configure --prefix=$PWD/install

Make sure to run `make install`.

Then `$PWD/install/bin/babeltrace2` is fully installed and independent
and will load the correct libbabeltrace2 because it has
`$PWD/install/lib` as its runpath.

You may debug as usual:

    $ gdb --args ./install/bin/babeltrace2 [...]

Philippe

> Is there a way to specify the library path? Because even with the libtool wrapper, GDB uses the release version of libbabeltrace2.so.0.
>
> You're helping me a lot, thank you! :)
> I hope you have a great day!
>
> Kind regards,
> Aron
> __________
> Aron Seidl
> DH-Student IT Education
>
> Carl Zeiss AG
> Carl-Zeiss-Strasse 22
> 73447 Oberkochen, Deutschland
>
> aron.seidl@zeiss.com
> http://www.zeiss.de/
> __________
> Carl Zeiss AG
> Sitz der Gesellschaft: Oberkochen, Deutschland
> Vorsitzender des Aufsichtsrates: Dr. Michael Bolle
> Vorstand: Dr. Karl Lamprecht (Vorsitzender),
> Susan-Stefanie Breitkopf, Sven Hermann, Dr. Christian Müller,
> Andreas Pecher, Dr. Jochen Peter, Dr. Markus Weber
> Amtsgericht Ulm, HRB 501 555, USt-IdNr: DE 811 119 940
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Simon Marchi <simark@simark.ca>
> Gesendet: Dienstag, 24. Oktober 2023 20:52
> An: Seidl, Aron <aron.seidl@zeiss.com>; lttng-dev@lists.lttng.org
> Betreff: Re: [lttng-dev] Debugging Libaries in Babeltrace 2
>
> 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
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

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

[Simon Marchi via lttng-dev]

On 10/25/23 03:29, Seidl, Aron via lttng-dev wrote:
> Hi Simon,
> Thanks for your quick answer!
> I run GDB like this:
> gdb --args ./babeltrace2 /home/aron/Schreibtisch/kernel4 -o text
> (I'm in src/cli/.libs)

Don't do that (try to debug the binary in .libs directly).

> I don't think I've ever installed a System Version of babeltrace2, so it is really weird that GDB uses following library:
> 
> 0x00007ffff7f36f00  0x00007ffff7f89749  Yes (*)     /lib/x86_64-linux-gnu/libbabeltrace2.so.0
> (*): Shared library is missing debugging information.

It might have been installed as a dependency of another package, I don't
know.

> And you're absolutely right! That is the reason why I can't debug it.
> Is there a way to specify the library path? Because even with the libtool wrapper, GDB uses the release version of libbabeltrace2.so.0.

Can you run this *in the root of your build tree* and show the output?
We should see a path to libbabeltrace2.so inside your build tree.

$ libtool --mode=execute gdb -q -batch src/cli/babeltrace2 -ex start -ex "info shared"

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

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

[Seidl, Aron via lttng-dev]

Thank you guys!!!!

You helped me a lot, It works now. You guys are the best!

I wish you a great day!

Thanks again!

Sincerely,
Aron

__________
Aron Seidl
DH-Student IT Education

Carl Zeiss AG
Carl-Zeiss-Strasse 22
73447 Oberkochen, Deutschland

aron.seidl@zeiss.com
http://www.zeiss.de/
__________
Carl Zeiss AG
Sitz der Gesellschaft: Oberkochen, Deutschland
Vorsitzender des Aufsichtsrates: Dr. Michael Bolle
Vorstand: Dr. Karl Lamprecht (Vorsitzender),
Susan-Stefanie Breitkopf, Sven Hermann, Dr. Christian Müller,
Andreas Pecher, Dr. Jochen Peter, Dr. Markus Weber
Amtsgericht Ulm, HRB 501 555, USt-IdNr: DE 811 119 940




-----Ursprüngliche Nachricht-----
Von: Philippe Proulx <eeppeliteloop@gmail.com>
Gesendet: Mittwoch, 25. Oktober 2023 16:51
An: Seidl, Aron <aron.seidl@zeiss.com>
Cc: Simon Marchi <simark@simark.ca>; lttng-dev@lists.lttng.org
Betreff: Re: [lttng-dev] Debugging Libaries in Babeltrace 2

On Wed, Oct 25, 2023 at 3:29 AM Seidl, Aron via lttng-dev <lttng-dev@lists.lttng.org> wrote:
>
> Hi Simon,
> Thanks for your quick answer!
> I run GDB like this:
> gdb --args ./babeltrace2 /home/aron/Schreibtisch/kernel4 -o text (I'm
> in src/cli/.libs)
>
> I don't think I've ever installed a System Version of babeltrace2, so it is really weird that GDB uses following library:
>
> 0x00007ffff7f36f00  0x00007ffff7f89749  Yes (*)     /lib/x86_64-linux-gnu/libbabeltrace2.so.0
> (*): Shared library is missing debugging information.
>
> And you're absolutely right! That is the reason why I can't debug it.

Note that you can also install the project locally:

    $ BABELTRACE_DEV_MODE=1 BABELTRACE_MINIMAL_LOG_LEVEL=TRACE \
      BABELTRACE_DEBUG_MODE=1 CFLAGS='-g -O0' CPPFLAGS='-g -O0' \
      ./configure --prefix=$PWD/install

Make sure to run `make install`.

Then `$PWD/install/bin/babeltrace2` is fully installed and independent and will load the correct libbabeltrace2 because it has `$PWD/install/lib` as its runpath.

You may debug as usual:

    $ gdb --args ./install/bin/babeltrace2 [...]

Philippe

> Is there a way to specify the library path? Because even with the libtool wrapper, GDB uses the release version of libbabeltrace2.so.0.
>
> You're helping me a lot, thank you! :) I hope you have a great day!
>
> Kind regards,
> Aron
> __________
> Aron Seidl
> DH-Student IT Education
>
> Carl Zeiss AG
> Carl-Zeiss-Strasse 22
> 73447 Oberkochen, Deutschland
>
> aron.seidl@zeiss.com
> http://www.z/
> eiss.de%2F&data=05%7C01%7C%7C43f7247a492e49f2044e08dbd569f348%7C280422
> 44bb514cd680347776fa3703e8%7C0%7C0%7C638338423263867029%7CUnknown%7CTW
> FpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7C%7C&sdata=MLn%2FZ%2BCyUqlP%2B1p2M0P4qTkC83FCV0EhqSt
> gUzIl6Ok%3D&reserved=0
> __________
> Carl Zeiss AG
> Sitz der Gesellschaft: Oberkochen, Deutschland Vorsitzender des
> Aufsichtsrates: Dr. Michael Bolle
> Vorstand: Dr. Karl Lamprecht (Vorsitzender), Susan-Stefanie Breitkopf,
> Sven Hermann, Dr. Christian Müller, Andreas Pecher, Dr. Jochen Peter,
> Dr. Markus Weber Amtsgericht Ulm, HRB 501 555, USt-IdNr: DE 811 119
> 940
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Simon Marchi <simark@simark.ca>
> Gesendet: Dienstag, 24. Oktober 2023 20:52
> An: Seidl, Aron <aron.seidl@zeiss.com>; lttng-dev@lists.lttng.org
> Betreff: Re: [lttng-dev] Debugging Libaries in Babeltrace 2
>
> 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%2Fsoftware%2Flibtool%2Fmanual%2Fhtml_node%2FDebugging-executab
> les.html&data=05%7C01%7C%7C43f7247a492e49f2044e08dbd569f348%7C28042244
> bb514cd680347776fa3703e8%7C0%7C0%7C638338423263867029%7CUnknown%7CTWFp
> bGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn
> 0%3D%7C3000%7C%7C%7C&sdata=mLqnXa60EJZu9TTWilgsSwmLdLyGkvlYe6FByA6xUko
> %3D&reserved=0
>
> Simon
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> https://list/
> s.lttng.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Flttng-dev&data=05%7C01%7C
> %7C43f7247a492e49f2044e08dbd569f348%7C28042244bb514cd680347776fa3703e8
> %7C0%7C0%7C638338423263867029%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAw
> MDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sda
> ta=4yROBhlPmhJnRMN30NpUhK3a7mLIbk%2B%2BnPHinhEF87U%3D&reserved=0
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev