FS#60651 - [gcc-libs] Add tracing probes to libstdc++ for exceptions
Attached to Project:
Arch Linux
Opened by Daniel Lopez (FelledTreeNo9) - Wednesday, 31 October 2018, 01:26 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Thursday, 24 October 2019, 16:27 GMT
Opened by Daniel Lopez (FelledTreeNo9) - Wednesday, 31 October 2018, 01:26 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Thursday, 24 October 2019, 16:27 GMT
|
Details
It would be useful if libstdc++.so was built with Tom
Tromey's statically defined tracing probes, to improve
debuggability of C++ exceptions in GDB.
The GDB 'catch' command, that stops at various kinds of events including C++ exceptions, can be set to stop only on exceptions of a specific type - but without the aforementioned probes it just stops on every exception regardless of type. Also, the special variable '$_exception' that would give you details about the exception is subsequently missing, and in general all the stuff to do with exceptions and GDB is kind of flaky. You can check for the presence of the probes with the command: readelf -n /lib/libstdc++.so.6.0.25 When present you'll see something like: """ Displaying notes found in: .note.gnu.build-id Owner Data size Description GNU 0x00000014 NT_GNU_BUILD_ID (unique build ID bitstring) Build ID: 0972dabed9d271753baf023aca990613ddb217b6 Displaying notes found in: .note.stapsdt Owner Data size Description stapsdt 0x0000003b NT_STAPSDT (SystemTap probe descriptors) Provider: libstdcxx Name: catch Location: 0x000000000008e0ff, Base: 0x000000000013bff8, Semaphore: 0x0000000000000000 Arguments: 8@%rax 8@-80(%rbx) stapsdt 0x00000036 NT_STAPSDT (SystemTap probe descriptors) Provider: libstdcxx Name: throw Location: 0x000000000008f26d, Base: 0x000000000013bff8, Semaphore: 0x0000000000000000 Arguments: 8@%rdi 8@%rsi stapsdt 0x0000003a NT_STAPSDT (SystemTap probe descriptors) Provider: libstdcxx Name: rethrow Location: 0x000000000008f328, Base: 0x000000000013bff8, Semaphore: 0x0000000000000000 Arguments: 8@%rax 8@(%rdi) """ That was copied from a Debian install; on my Arch install I don't have the ".note.stapsdt" section. I've also found the probes present in an Ubuntu and Fedora install. The probes get added when this test from libstdc++-v3 configure script passes: "checking for suitable sys/sdt.h", which tries to #include <sys/sdt.h>. Systemtap (AUR [https://aur.archlinux.org/packages/systemtap]) includes this file, putting it at /usr/include/sys/sdt.h. Perhaps systemtap could be made a build dependency of gcc, but I suppose it's a big add for the sake of a single file. It looks like what Debian did was make a small systemtap-sdt-dev that is pared down to a few essentials. [https://packages.debian.org/stretch/amd64/systemtap-sdt-dev/filelist] From my own tests in building the gcc package with the probes I've found that at minimum it just needs /usr/include/sys/sdt.h to be present and also /usr/include/sys/sdt-config.h alongside it. The dtrace executable that the Debian package has isn't strictly necessary for this purpose. So ultimately my request is, please could those two files be somehow made prerequisites of the gcc build? I took my own built libstdc++.so.6.0.25 with the probes and installed it in /lib and rebooted and it does fix the issues I originally had with GDB. Here are some links to posts by Tom in case you want to read more in detail: http://tromey.com/blog/?p=687 https://patchwork.ozlabs.org/patch/223711/ https://gcc.gnu.org/ml/libstdc%2B%2B/2013-03/msg00060.html |
This task depends upon
Closed by Bartłomiej Piotrowski (Barthalion)
Thursday, 24 October 2019, 16:27 GMT
Reason for closing: Fixed
Thursday, 24 October 2019, 16:27 GMT
Reason for closing: Fixed
Comment by
Bartłomiej Piotrowski (Barthalion)
- Wednesday, 28 November 2018, 10:24 GMT
Yeah, given systemtap requires CONFIG_DEBUG_INFO enabled in
kernel, I may create a package with required headers only instead.
I will take a look on Friday.
Comment by
Bartłomiej Piotrowski (Barthalion)
- Thursday, 24 October 2019, 16:26 GMT
STD will be part of glibc 2.30-2. GCC will be rebuild with it
eventually.
Comment by
Bartłomiej Piotrowski (Barthalion)
- Thursday, 24 October 2019, 16:26 GMT
(To clarify, it's downstream change. It's not something upstream
did.)