This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFA] Improved linker-debugger interface
> From: Tom Tromey <tromey@redhat.com>
> Date: Tue, 08 May 2012 07:37:12 -0600
>
> >>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:
>
> Mark> I'm pretty annoyed by the whole SystemTap thing. You presented this
> Mark> as being something pretty generic. But it turns out this is not only
> Mark> Linux-specfic, but pretty much a completely RedHat-specific thing it
> Mark> seems. And I think I've figured out why: SystemTap relies on utrace,
> Mark> which is not present in the official Linux kernel source tree. And as
> Mark> far as I can see it will remain that way in the near future. So
> Mark> unless you are running RedHat Linux, you'll not only need to build a
> Mark> patched glibc, but you also need to build a patched kernel to be able
> Mark> to use these new SystemTap probes. Not many people will do that!
>
> None of this is the accurate.
>
> I'm also annoyed now, because I explained all this at length, twice, and
> also sent references to the documentation, explaining how the probe
> feature is a relatively generic ELF feature, not dependent on the main
> body of System Tap at all. Apparently you didn't read any of this.
Sorry, but I looked back in my private mail archive and the mailing
list archives, and I couldn't find a mail from you with references to
documentation. I did some digging around myself, and landed at:
<http://sourceware.org/systemtap/SystemTap_Beginners_Guide/userspace-probing.html>
which mentions the dependency on utrace quite prominently.
Combined with your reply to one of my questions:
> Mark> So you are saying that, at least in principle, it should be possible
> Mark> to use the SystemTap toolchain on any ELF-based system to do
> Mark> user-space tracing without needing any kernel support? That'd be cool.
> Nope, just the static markers coming from <sdt.h>. The rest of
> SystemTap is Linux-specific, dynamically creating and loading kernel
> modules.
This confused me enough to think that kernel support was necessary for
GDB's usage of the probes as well.
> To sum up again, the code in gdb relates to static probe points.
>
> From the user's point of view, a probe is a spot in the code with a name
> and arguments.
>
> From the implementation point of view, a probe is an entry in an ELF
> section, designed in a way to minimize overhead, plus a no-op in the
> code.
>
> GDB reads this new section and uses it to find the probe points, and to
> decode the probe arguments. There is zero dependency on System Tap, or
> the kernel, or utrace, or anything else. It is purely reading an ELF
> section.
>
> The probe implementation is a header file. Currently this is maintained
> in System Tap. However, even this is relatively independent; it depends
> on a GCC extension, but this is part of upstream GCC. I would not be
> surprised if this code worked on any GCC/ELF system.
Thanks for explaining this again. This makes it crystal clear.
> Mark> Having the basic SystemTap support in GDB is fine. But depending on
> Mark> it to fix issues with core GDB functionality like the ability to debug
> Mark> shared libraries is a different matter. It means that people using
> Mark> RedHat Linux, almost certainly including any RedHat engineers
> Mark> contributing here will no longer test the codepaths that don't rely on
> Mark> SystemTap. And people on other Linux variants will never test the
> Mark> codepaths that rely on SystemTap. That'll inevitably lead to more
> Mark> breakage.
>
> This is already the situation for compilers and kernels, which in
> practice touch much more code in gdb.
Yes, but reduction of the number of code paths is still a worthy goal.
Anyway, with my misunderstandings about SystemTap cleared up, my
reservations about using probes to handle runt-time linker events are
gone. I still do think that having those probes in the official glibc
tree should be a prerequisite for ading this code to glibc. These
probes effectively become part of the libc ABI[1]. We need some sort
of commitment from the glibc developers to not break that ABI. And in
my view the only way to achieve this is to have those probes upstream.
[1] This contradicts what Roland McGrath wrote on the libc-lpha mailing list
http://sourceware.org/ml/libc-alpha/2011-03/msg00001.html