This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: failed to trace printf


Hi Srikar,

On Thu, 2009-06-11 at 19:30 +0530, Srikar Dronamraju wrote:
> 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.

Yes, if we would use the elf symbol table we could do that.
As far as I understand that is precisely what the bug report is about:
http://sourceware.org/bugzilla/show_bug.cgi?id=6864 

> 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.

Yes indeed. If we would have only the elf symbol table address then we
could probe, but not access any variables.

In this case though it seems a good idea to look at whether we can
provide a patch for glibc to add dwarf debuginfo for this assembler
function so both stap and gdb can access arguments (and unwind from it).

Cheers,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]