Re: [RFA] Improved linker-debugger interface

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> 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