* [lttng-dev] Debugging Libaries in Babeltrace 2 @ 2023-10-24 15:52 Seidl, Aron via lttng-dev 2023-10-24 18:51 ` Simon Marchi via lttng-dev 0 siblings, 1 reply; 6+ messages in thread From: Seidl, Aron via lttng-dev @ 2023-10-24 15:52 UTC (permalink / raw) To: 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [lttng-dev] Debugging Libaries in Babeltrace 2 2023-10-24 15:52 [lttng-dev] Debugging Libaries in Babeltrace 2 Seidl, Aron via lttng-dev @ 2023-10-24 18:51 ` Simon Marchi via lttng-dev 2023-10-25 7:29 ` Seidl, Aron via lttng-dev 0 siblings, 1 reply; 6+ messages in thread From: Simon Marchi via lttng-dev @ 2023-10-24 18:51 UTC (permalink / raw) To: Seidl, Aron, 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [lttng-dev] Debugging Libaries in Babeltrace 2 2023-10-24 18:51 ` Simon Marchi via lttng-dev @ 2023-10-25 7:29 ` Seidl, Aron via lttng-dev 2023-10-25 14:50 ` Philippe Proulx via lttng-dev 2023-10-25 15:31 ` Simon Marchi via lttng-dev 0 siblings, 2 replies; 6+ messages in thread From: Seidl, Aron via lttng-dev @ 2023-10-25 7:29 UTC (permalink / raw) To: Simon Marchi, 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [lttng-dev] Debugging Libaries in Babeltrace 2 2023-10-25 7:29 ` Seidl, Aron via lttng-dev @ 2023-10-25 14:50 ` Philippe Proulx via lttng-dev 2023-10-26 10:21 ` Seidl, Aron via lttng-dev 2023-10-25 15:31 ` Simon Marchi via lttng-dev 1 sibling, 1 reply; 6+ messages in thread From: Philippe Proulx via lttng-dev @ 2023-10-25 14:50 UTC (permalink / raw) To: Seidl, Aron; +Cc: Simon Marchi, 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [lttng-dev] Debugging Libaries in Babeltrace 2 2023-10-25 14:50 ` Philippe Proulx via lttng-dev @ 2023-10-26 10:21 ` Seidl, Aron via lttng-dev 0 siblings, 0 replies; 6+ messages in thread From: Seidl, Aron via lttng-dev @ 2023-10-26 10:21 UTC (permalink / raw) To: Philippe Proulx; +Cc: Simon Marchi, 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [lttng-dev] Debugging Libaries in Babeltrace 2 2023-10-25 7:29 ` Seidl, Aron via lttng-dev 2023-10-25 14:50 ` Philippe Proulx via lttng-dev @ 2023-10-25 15:31 ` Simon Marchi via lttng-dev 1 sibling, 0 replies; 6+ messages in thread From: Simon Marchi via lttng-dev @ 2023-10-25 15:31 UTC (permalink / raw) To: Seidl, Aron, 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2023-10-26 10:22 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-10-24 15:52 [lttng-dev] Debugging Libaries in Babeltrace 2 Seidl, Aron via lttng-dev 2023-10-24 18:51 ` Simon Marchi via lttng-dev 2023-10-25 7:29 ` Seidl, Aron via lttng-dev 2023-10-25 14:50 ` Philippe Proulx via lttng-dev 2023-10-26 10:21 ` Seidl, Aron via lttng-dev 2023-10-25 15:31 ` Simon Marchi via lttng-dev
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox