This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: failed to trace printf
Hi Mark,
Thanks for quick and detailed reply.
> >
> > # 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.
If we are unable to find debuginfo for a symbol, can we see if we have
alias functions like __printf in this case. (When I mean alias
functions, I refer to functions are having the same address). Can we use
the debuginfo of the alias function. Here __printf and printf are
having same address 000000000004fdb0. It may not be that easy. Probably
there are easier methods to do also.
>
> > 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.
>
I ran gdb on a program and it seems to refer gdb is able to refer to
/usr/src/debug////////glibc-20081113T2206/string/../sysdeps/x86_64/strcmp.S
gdb is able to say when the breakpoint corresponding to strcmp is hit.
Though it was unable to give out variable info. Can we look at something
similar in stap? I mean we probe the function but say No local variable info
when ever we refer to variables.
--
Thanks and Regards
Srikar