This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: probe point "process(PATH).library("/lib64/libc.so.6").function("open") no match ERROR.
- From: fche at redhat dot com (Frank Ch. Eigler)
- To: maliubiao <maliubiao at gmail dot com>
- Cc: systemtap at sourceware dot org, scox at redhat dot com
- Date: Sat, 17 Aug 2013 20:05:34 -0400
- Subject: Re: probe point "process(PATH).library("/lib64/libc.so.6").function("open") no match ERROR.
- References: <CAFiE4-4AR6uhEdGMXbOSzRXQegKJvA3EcEp20WEPzuE5F5_sUA at mail dot gmail dot com>
maliubiao wrote:
> I am trying to trace functions in libc .
> Do nm /lib64/libc.so.6 |grep open , actually there is a weak symbol open [...]
There are a couple of separate problems here.
open, aka __open, is a function defined in assembly language (glibc
../sysdeps/unix/syscall-template.S), for which no DWARF debuginfo is
being emitted by glibc's build process. (It should be; they should
use ASFLAGS+=--gdwarf2.) Systemtap cannot properly see these:
http://sourceware.org/bugzilla/show_bug.cgi?id=10208.
We also have a shared-library-PLT based mechanism:
probe process("/lib64/libc.so.6").plt("open") { }
This should resolve. However, due to verification associated with
the prior PR, this gets rejected (and indeed very few .plt("*")
probes resolve for glibc). Stan, can we do something about this?
> Is there a way to trace weak symbol or to find out what symbol do a
> weak symbol actually refer to?
Weak symbols per se are not a big problem. We already handle those
to some extent.
- FChE