This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: failed to trace printf
- From: Mark Wielaard <mjw at redhat dot com>
- To: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- Cc: SystemTap ML <systemtap at sourceware dot org>
- Date: Thu, 11 Jun 2009 14:29:14 +0200
- Subject: Re: failed to trace printf
- References: <20090611115059.GA11434@linux.vnet.ibm.com>
Hi Srikar,
On Thu, 2009-06-11 at 17:20 +0530, Srikar Dronamraju wrote:
> I was trying to trace libc functions using SystemTap.
> Strangely there were couple of functions that failed.
> Can you let me know what could be the reason?
It is because we rely on funding functions through the debuginfo, not
through the elf symbol table. If there is no dwarf information for the
function name/alias then we won't find it. This is:
http://sourceware.org/bugzilla/show_bug.cgi?id=6864
> I am trying these with fedora 10 system on a x86_64 with systemtap
> installed from this week's systemtap snapshot.
>
> # nm /lib64/libc.so.6 | grep -w -e __printf -e printf
> 000000000004fdb0 t __printf
> 000000000004fdb0 T printf
> #
>
> It fails for printf and works well for __printf.
> I actually expected it to be the other way.
So this just means that __printf has debuginfo associated with it and so
we are able to find it. But printf doesn't (directly) have debuginfo
associated with it, so we don't find it.
To see which functions stap can see try:
stap -l process("/lib64/libc.so.6").function("*")
Or if you have dwarfdump installed you could dump the debug symbols with
something like: dwarfdump -p /usr/lib/debug/lib/libc.so.6.debug
> Also I tried with strcmp and that also failed.
> # nm /lib64/libc.so.6 | grep strcmp
> 0000003497880880 t __GI_strcmp
> 0000003497880880 T strcmp
> #
>
> This time it failed for both _GI_strcmp and strcmp.
I haven't checked, but most likely strcmp is implemented through
assembler as doesn't have dwarf information, or gcc uses an strcmp
builtin function as optimization.
Cheers,
Mark