Re: [RFA] Improved linker-debugger interface

[Tom Tromey <tromey@redhat.com>]

>>>>> "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.


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.

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.

Tom