Re: about probe libc

[Roland McGrath <roland at redhat dot com>]

The RHEL5 debuginfo for libc (perhaps for all .so's?) has a CRC mismatch
with the .gnu_debuglink section embedded in the binary.  This indicates a
problem in the rpm build procedure, but the binaries are already built.
To avoid the CRC checking you can use a SYSTEMTAP_DEBUGINFO_PATH setting
that begins with - instead of +, for example:

SYSTEMTAP_DEBUGINFO_PATH=-/usr/lib/debug  stap -e 'probe process("/lib/libc.so.6").function("memcpy").return{println(probefunc())}' -c 'ls'

worked for me where it before got the same failure mode you saw.
("Worked" just meaning doesn't get that "No DWARF" error any more.)

The systemtap default path is:
	+:.debug:/usr/lib/debug:/var/cache/abrt-di/usr/lib/debug:build
That leading + flag (vs -) enables the CRC checking by default.

When disabling this check, you always need to double-check by hand that you
really have the correct .debug files installed to match the binaries you
are using (i.e. from foo-N-V-R.A.rpm and foo-debuginfo-N-V-R-A.rpm with
exactly matching N-V-R.A), because you are no longer getting any kind of
automatic checking that they are an exact match.

On systems newer than RHEL5 (e.g. Fedora >= 8, RHEL6), all the binaries and
.debug files will have build IDs.  When binaries have build IDs, those are
a reliable verification that you have the right files installed, and so the
CRC check is never consulted (whether it's correct, or broken as for RHEL5
libc.so.debug).  The - flag in the debuginfo path setting has no effect on
build ID checking, so, if you like, you can use a uniform setting both for
RHEL5 and for systems that do have build IDs, and lose nothing in the newer
and better environments.

Note that in this example I didn't see any probe hits, and that may well be
"correct".  memcpy is one of several special-case functions that (in
optimized code) are almost always either defined as macros or inlines in
header files, or directly compiled away by the compiler as a special built-in.

You are unlikely to be able to get any reliable probing of memcpy (or some
other examples like other simple <string.h> functions), except perhaps for
the calls in your own code if it is compiled without optimization (-O0).


Thanks,
Roland