probe point "process(PATH).library("/lib64/libc.so.6").function("open") no match ERROR.

probe point "process(PATH).library("/lib64/libc.so.6").function("open") no match ERROR.

[maliubiao]

I am trying to trace functions in libc .
Do nm /lib64/libc.so.6 |grep open ,  actually there is a weak symbol open,
When I use malloc instead of open in function("open"),  It works ,  in
the handler  the result of probefunc() is __libc_malloc.
__libc_malloc is a T symbol, which is in the CODE segment.

Is there a way  to trace weak symbol  or  to find out  what symbol  do
a weak symbol actually refer to?

Re: probe point "process(PATH).library("/lib64/libc.so.6").function("open") no match ERROR.

[Frank Ch. Eigler]

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