Re: [RFA] Improved linker-debugger interface

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Mark" == Mark Kettenis <mark.kettenis@xs4all.nl> writes:

Mark>   <http://sourceware.org/systemtap/SystemTap_Beginners_Guide/userspace-probing.html>

Mark> which mentions the dependency on utrace quite prominently.

You want http://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation

Mark> Anyway, with my misunderstandings about SystemTap cleared up, my
Mark> reservations about using probes to handle runt-time linker events are
Mark> gone.  I still do think that having those probes in the official glibc
Mark> tree should be a prerequisite for ading this code to glibc.  These
Mark> probes effectively become part of the libc ABI[1].  We need some sort
Mark> of commitment from the glibc developers to not break that ABI.  And in
Mark> my view the only way to achieve this is to have those probes upstream.

FWIW for the longjmp case, where the code is currently in-tree, there
really aren't alternative code paths to consider.  Due to PC mangling,
the existing longjmp code simply doesn't work with any glibc newer than
2006 or so.

I've asked the local glibc folks to try again to push the patches.

If you take Roland's lack of ABI promise seriously, and combine it with
your reasoning above, then we must never use these probes in gdb.  But,
that is an absurd result, since the probes basically exist for use by
gdb.

So, something has to give.

I think that if gdb were using the probes, we can use this to argue that
glibc should only make ABI-compatible changes.  The ABI rules for probes
are much more relaxed than the rules for normal C constructs, so this is
not a problem.

There are two choices for ABI compatible changes here; one is to keep
existing probe names and arguments, adding any needed new arguments to
the end of the list; or simply renaming the probes.  Deleting probes is
also ok (contrary to the usual glibc ABI rules), because gdb and other
users will always be adaptive.

In sum, I don't consider this a problem in practice.  I'm confident that
glibc maintainers will listen to reason.

Tom