merging roland/systemtap branch

[Roland McGrath <roland at redhat dot com>]

If there are no strenuous objections, I would like to merge the
roland/systemtap branch into the trunk ASAP.  I hope we can have
this in for the 2.14 release.  We'd like to have it in Fedora 15.

This adds the --enable-systemtap configure option, which defaults to off.
It has no effect whatosever on the compiled code without that option on.
With the option on, it requires the <sys/sdt.h> from systemtap 1.4 to
let its configure check pass and to build the library.

In another release cycle or two, I think we should consider making
--enable-systemtap default to on when the compatible <sys/sdt.h> is
detected by the configure check.  But for now, it defaults to off and
so nobody should be affected by the new code at all without going out
of their way to ask for it.

Systemtap 1.4 and later can make use of these probes to instrument the
libraries without needing debuginfo.  Work is underway on GDB support to
set breakpoints at these probes without debuginfo, and that is planned
to be completed in the Fedora 15 time frame (i.e. by around the time of
the 2.14 release if not before).

This adds the internal header include/stap-probe.h to provide LIBC_PROBE
and LIBC_PROBE_ASM macros.  These wrap the <sys/sdt.h> probe macros for
conditional use in libc source, where they can be used in both C and
assembly sources, as well as interspersed inside asm() constructs.

When configured in, each probe adds nothing to the actual code path except
for a single 'nop' instruction.  The metadata for the probes goes into a
non-allocated ELF notes section, and hence has no runtime effect.  There is
a single additional one-byte placeholder text section in the whole DSO,
which is necessary to let analysis of the static metadata compensate for
prelink adjustments to the code addresses.

I don't think the probe names and their argument semantics need to be
considered a part of the stable ABI.  Hence I don't think we need to
worry about the set of probes or their locations or their arguments
being changed in the future to make them more correct and more useful.
There is no versioning mechanism provided in the note format, only a
probe name string.  So far the uses of such probes are ad hoc, informal,
and adaptive to what probe details are found.  There may come a time
when things are really depending on some probe details (such as the GDB
feature I'll mention below), but for the foreseeable future nothing like
that is depended on for the essential functionality of anything.

On the branch, two sets of probes are added.  Both are only fully there
for x86-64 and i?86 configurations so far.

First, I've added probes in setjmp/longjmp for x86_64 and i?86.  There
is one probe in each variant of setjmp, and two probes in each variant
of longjmp.  The setjmp probes give three probe parameters that the
instrumentation can use: two matching the arguments to sigsetjmp (thus
the second is a constant 0 or 1 in the other variants), and a third that
is the return PC address stored in the jmp_buf, before PC mangling.
Both longjmp probes give the same three parameters.  There is a probe
called libc.longjmp that is before the jump happens, so that a backtrace
from that point shows the caller of longjmp.  There is a second probe
called libc.longjmp_target that is logically "after" the jump happens
(still actually in the longjmp code, but at the point where the CFI has
shifted), so that a backtrace from that point shows the caller of setjmp.

There are plans afoot to make GDB exploit one of these longjmp probes
automagically, to implement its "step over longjmp" feature more cleanly
than that's done today.  (I don't know much about the GDB stuff.  Ask
Tom Tromey on the archer@sourceware.org mailing list for details.)

Second, Rayson Ho <rho@redhat.com> has added probes in numerous places
in libpthread and the low-level locking code that exists both there and
in libc and ld.so.  These have been posted to libc-alpha before, and the
details of the probe locations and their arguments are fully described
in the nptl/DESIGN-systemtap-probes.txt file added by the branch.

I'll be shortly writing some tests for the setjmp/longjmp probes for the
systemtap test suite and verifying their functioning.  Rayson will be
working on uses and tests of the libpthread probes.  We'll send fixes
for any probe details as needed.

What say you?


Thanks,
Roland