|
From: Fabian W. <fab...@ls...> - 2007-03-22 13:20:38
|
Hello, is there a way to make a trace of the program run using valgrind/callgrind? Thanks, Fabian |
|
From: Julian S. <js...@ac...> - 2007-03-22 13:26:41
|
> is there a way to make a trace of the program run using valgrind/callgrind? There's lots of ways to get traces. Depends what you mean though - instruction level traces or syscall level traces or what? J |
|
From: Josef W. <Jos...@gm...> - 2007-03-22 14:13:38
|
On Thursday 22 March 2007, Fabian Wein wrote: > Hello, > > is there a way to make a trace of the program run using > valgrind/callgrind? You should state what kind of trace you want. E.g. you can get a call tree trace with valgrind --tool=callgrind --ct-verbose=1 ... Josef |
|
From: Julian S. <js...@ac...> - 2007-03-22 14:28:31
|
On Thursday 22 March 2007 14:13, Josef Weidendorfer wrote: > E.g. you can get a call tree trace with > valgrind --tool=callgrind --ct-verbose=1 ... Wow. I didn't know that. Is there anything callgrind _can't_ do :-? J |
|
From: Josef W. <Jos...@gm...> - 2007-03-22 15:04:32
|
On Thursday 22 March 2007, Julian Seward wrote: > On Thursday 22 March 2007 14:13, Josef Weidendorfer wrote: > > > E.g. you can get a call tree trace with > > valgrind --tool=callgrind --ct-verbose=1 ... > > Wow. I didn't know that. Is there anything callgrind _can't_ do :-? Let me see... make coffee? More seriously, that really is just debugging output to see if the calls and returns are recognized correctly. And if you run this on PPC, you will see how badly screwed up the call/return detection heuristic on this platform currently is :-( A time ago there was somebody working to improve this. However, I do not know about the current status there. Obviously, that debugging output seems to be useful also for other purposes (*1*). However, it really would be nice to correctly parse DWARF debug info to also see the correct parameter names, types and values; theoretically, this should be possible (*2*). Josef (*1*) E.g., I know about some program which generates UML sequence diagrams for a C++ program (as SVG) by using this output ;-) (*2*) Nice phrase I heard today: "The difference between theory and practice is in practice greater than in theory". |
|
From: Fabian W. <fab...@ls...> - 2007-03-22 15:36:17
|
Hello Josef,
>> is there a way to make a trace of the program run using
>> valgrind/callgrind?
>
> You should state what kind of trace you want.
>
> E.g. you can get a call tree trace with
> valgrind --tool=callgrind --ct-verbose=1 ...
Thanks for the qick answer, but this is not what I want.
I want a (human readable) call-graph like
main()
Class::Class()
Class::Init()
Class:run()
AnotherClass::AnotherClass()
Matrix::Matrix()
Vector::Vector()
Vector::Vector()
Matrix::Multiply(Vector)
AnotherClass::~AnotherClass()
Class::~Class()
Is this possible?
BTW, is the UML generating tool available, and are the graphs readable?
Thanks,
Fabian
|
|
From: Josef W. <Jos...@gm...> - 2007-03-22 16:44:45
|
On Thursday 22 March 2007, Fabian Wein wrote: > > valgrind --tool=callgrind --ct-verbose=1 ... > Thanks for the qick answer, but this is not what I want. > > I want a (human readable) call-graph like > > main() > Class::Class() > Class::Init() > Class:run() > AnotherClass::AnotherClass() > Matrix::Matrix() > Vector::Vector() > Vector::Vector() > Matrix::Multiply(Vector) > AnotherClass::~AnotherClass() > Class::~Class() Hmm. This is not a call-graph, as a graph can not have multiple nodes with the same label. So I suppose this actually is the call tree, sorted according to time? Then '--ct-verbose=1' actually should exactly be the thing you want here, or you have to explain in more detail what you want. As I said, it could have a nicer format. The main thing you seem missing is filtering the lines, like to only show the call tree inside of function main()? That actually is easy (I know, strange way to specify 2 args in one option): valgrind --tool=callgrind --ct-verbose1='main()' ... Meaning: "Switch verbose level to 1 when entering 'main()' and back to the previous level when leaving 'main()'". You need to exactly specify the symbol name here, which includes the parenthesis for C++ code (BTW, shouldn't this be 'main(int,char*[])' ?). And you probably want to not see all the stuff from the runtime linker. It should work with an additional option "--ct-verbose0='_dl_runtime_resolve'", but there is a bug in the option parser. Instead you could do something like valgrind --tool=callgrind --ct-verbose=1 ... 2>&1 | grep -v ld-2.5.so (for me, the runtime linker is in shared library ld-2.5.so). Josef |
|
From: Ashley P. <as...@qu...> - 2007-03-30 09:42:14
|
Josef Weidendorfer wrote: > On Thursday 22 March 2007, Fabian Wein wrote: >> Hello, >> >> is there a way to make a trace of the program run using >> valgrind/callgrind? > > You should state what kind of trace you want. > > E.g. you can get a call tree trace with > valgrind --tool=callgrind --ct-verbose=1 ... > That is truly awesome! It would benefit from strace like command line options and possible a cleaner output format but I can see it being very useful nevertheless. Ashley, |
|
From: Josef W. <Jos...@gm...> - 2007-03-30 11:22:34
|
On Friday 30 March 2007, Ashley Pittman wrote: > Josef Weidendorfer wrote: > > On Thursday 22 March 2007, Fabian Wein wrote: > >> Hello, > >> > >> is there a way to make a trace of the program run using > >> valgrind/callgrind? > > > > You should state what kind of trace you want. > > > > E.g. you can get a call tree trace with > > valgrind --tool=callgrind --ct-verbose=1 ... > > > > That is truly awesome! It would benefit from strace like command line > options and possible a cleaner output format but I can see it being very > useful nevertheless. What about making a new tool out of it? It really would be _especially_ nice to print the function parameters with correct types, using DWARF debug info. The call tracing can be extracted as a kind of a module which tools can combine. The problem is that every such module could have its own instrumentation requirements, and there could be conflicts combining multiple instrumentations. Hmm... perhaps it would be enough for such modules to document their instrumentation needs (such as "module X needs a helper call to y at start of every BB" or "module X wants to scan the SB and insert an IR snippet before every exit"), and let the tool author do the actual instrumentation manually as it is done now. Josef |
|
From: Nicholas N. <nj...@cs...> - 2007-04-01 08:43:34
|
On Fri, 30 Mar 2007, Josef Weidendorfer wrote: >>> E.g. you can get a call tree trace with >>> valgrind --tool=callgrind --ct-verbose=1 ... >> >> That is truly awesome! It would benefit from strace like command line >> options and possible a cleaner output format but I can see it being very >> useful nevertheless. > > What about making a new tool out of it? > It really would be _especially_ nice to print the function parameters with > correct types, using DWARF debug info. > > The call tracing can be extracted as a kind of a module which tools can > combine. The problem is that every such module could have its own > instrumentation requirements, and there could be conflicts combining > multiple instrumentations. > > Hmm... perhaps it would be enough for such modules to document their > instrumentation needs (such as "module X needs a helper call to y at start of > every BB" or "module X wants to scan the SB and insert an IR snippet > before every exit"), and let the tool author do the actual instrumentation > manually as it is done now. That would be very nice if it could be done in a clean way. It's one of those things that could be useful in a range of contexts but is actually really hard to do well, because of all the weird cases (PLT, longjmp/setjmp, tail recursion, etc). Nick |
|
From: Nicholas N. <nj...@cs...> - 2007-04-01 08:48:14
|
On Sun, 1 Apr 2007, Nicholas Nethercote wrote: >> What about making a new tool out of it? >> It really would be _especially_ nice to print the function parameters with >> correct types, using DWARF debug info. >> >> The call tracing can be extracted as a kind of a module which tools can >> combine. The problem is that every such module could have its own >> instrumentation requirements, and there could be conflicts combining >> multiple instrumentations. >> >> Hmm... perhaps it would be enough for such modules to document their >> instrumentation needs (such as "module X needs a helper call to y at start of >> every BB" or "module X wants to scan the SB and insert an IR snippet >> before every exit"), and let the tool author do the actual instrumentation >> manually as it is done now. > > That would be very nice if it could be done in a clean way. It's one of > those things that could be useful in a range of contexts but is actually > really hard to do well, because of all the weird cases (PLT, longjmp/setjmp, > tail recursion, etc). Thinking some more, it shouldn't be that hard. You'd have events like "enter_function" and "exit_function", which would get passed the function name and start address. (You'd have to make clear that enter_function/exit_function aren't always well-matched.) It could be added in an instrumentation pass like the one used for the new_mem_stack/die_mem_stack events. Nick |
|
From: Josef W. <Jos...@gm...> - 2007-04-01 09:59:49
|
On Sunday 01 April 2007, Nicholas Nethercote wrote: > On Sun, 1 Apr 2007, Nicholas Nethercote wrote: > >> Hmm... perhaps it would be enough for such modules to document their > >> instrumentation needs (such as "module X needs a helper call to y at start of > >> every BB" or "module X wants to scan the SB and insert an IR snippet > >> before every exit"), and let the tool author do the actual instrumentation > >> manually as it is done now. > > > > That would be very nice if it could be done in a clean way. It's one of > > those things that could be useful in a range of contexts but is actually > > really hard to do well, because of all the weird cases (PLT, longjmp/setjmp, > > tail recursion, etc). > > Thinking some more, it shouldn't be that hard. You'd have events like > "enter_function" and "exit_function", which would get passed the function > name and start address. (You'd have to make clear that > enter_function/exit_function aren't always well-matched. But the nice thing here is that these functions really _are_ well matched :-) The whole thing of the shadow stack is to ensure this, with the automatic unwinding via synchronization with the real stack, taking thread IDs and signal handlers into account, and which makes it robust (e.g. with longjmp's). Otherwise, callgrind would not work. In addition, we probably want to allow the tool to request the state of the shadow stack at any point. IMHO backtraces got this way are potentially more useful than the ones got from the physical stack. Of course, the semantic differences have to explained in detail. > ) It could be added > in an instrumentation pass like the one used for the > new_mem_stack/die_mem_stack events. Oh, I never looked at these. Are these adding additional instrumentation after/before the tools instrumentation phase? Josef > > Nick > |
|
From: Nicholas N. <nj...@cs...> - 2007-04-01 11:11:50
|
On Sun, 1 Apr 2007, Josef Weidendorfer wrote: >> ) It could be added >> in an instrumentation pass like the one used for the >> new_mem_stack/die_mem_stack events. > > Oh, I never looked at these. > Are these adding additional instrumentation after/before the tools instrumentation > phase? Yes. VEX even has a slot for a second instrumentation pass especially for it. Nick |
|
From: Josef W. <Jos...@gm...> - 2007-04-01 10:07:21
|
On Saturday 31 March 2007, Andi Kleen wrote: > Ashley Pittman <as...@qu...> writes: > > > Josef Weidendorfer wrote: > > > On Thursday 22 March 2007, Fabian Wein wrote: > > >> Hello, > > >> > > >> is there a way to make a trace of the program run using > > >> valgrind/callgrind? > > > > > > You should state what kind of trace you want. > > > > > > E.g. you can get a call tree trace with > > > valgrind --tool=callgrind --ct-verbose=1 ... > > > > > > > That is truly awesome! It would benefit from strace like command line > > options and possible a cleaner output format but I can see it being very > > useful nevertheless. > > Agreed. Strangely the option is not documented either in the usage > nor in the manpage? As I said before, this is pure debug output, at verbose level 1. It was never meant to be for the end user, and as it is now, it really still is subject to change at minor versions of VG. If there is interest from users, and we really want to support it as some kind of first class VG usage, I can try to make a new tool out of it. BTW, with "--help-debug", you see the option "--ct-verbose" ;-) But I admit that nowhere it is mentioned what the debug output is at different verbose levels. > I also noticed it only seems to resolve libc calls to symbols, but not internal > functions (like main) even though the debuginfo of the program is installed and > valgrind opened it. Hmm... that should not happen, as VG's debug info is used as usual. What VG version, what distribution? Josef > > -Andi > |
|
From: Nicholas N. <nj...@cs...> - 2007-04-01 11:13:05
|
On Sun, 1 Apr 2007, Josef Weidendorfer wrote: > If there is interest from users, and we really want to support it as some > kind of first class VG usage, I can try to make a new tool out of it. That would be interesting, and great for seeing how complex the tracking is. I wrote a tool that did this a couple of years ago, but it didn't handle all the obscure cases that Callgrind does. Nick |
|
From: Josef W. <Jos...@gm...> - 2007-04-03 17:23:58
|
On Sunday 01 April 2007, Andi Kleen wrote:
> Supporting it generally would be useful imho.
>
> > Hmm... that should not happen, as VG's debug info is used as usual.
> > What VG version, what distribution?
>
> SUSE 10.2, valgrind-3.2.1-21 as shipped
I have exactly the same.
> I tested it with ssh by installing ssh-debuginfo and then tracing it.
I only have openssh package here.
However, running
/usr/bin/valgrind --tool=callgrind --ct-verbose=1 ssh &> ssh.log
and search for "main" in ssh.log, I see
==================================================================
> (below main)(0x6D00, 0x1, ...) [libc-2.5.so / 0x15EC0]
.> 0x00015DE0(0x47FF4, 0x1, ...) [libc-2.5.so / 0x15DE0]
.> __cxa_atexit(0x400E1D0, 0x0, ...) [libc-2.5.so / 0x2BE20]
. > 0x00015DE0(0x4C64FF4, 0x4C6A896, ...) [libc-2.5.so / 0x15DE0]
. > __new_exitfn(0x4C64FF4, 0x1, ...) [libc-2.5.so / 0x2BCA0]
. > 0x00015DE0(0xBEBBAC08, 0x489B3EA, ...) [libc-2.5.so / 0x15DE0]
.> __libc_csu_init(0x1, 0xBEBBAC94, ...) [ssh / 0x3A3E0]
. > 0x00005FB7(0x4C64FF4, 0x401BCE0, ...) [ssh / 0x5FB7]
. > 0x00004D10(0x4960EF6, 0xBEBBAC9C, ...) [ssh / 0x4D10]
. > 0x00005EF8(0x481D590, 0x4B66CB5, ...) [ssh / 0x5EF8]
. > 0x00005F80(0x481D590, 0x4B66CB5, ...) [ssh / 0x5F80]
. > 0x00005FB7(0x47FF4, 0xBEBBABD8, ...) [ssh / 0x5FB7]
. > 0x0003A470(0x481D590, 0x4B66CB5, ...) [ssh / 0x3A470]
. > 0x00005FB7(0x47FF4, 0x401BCE0, ...) [ssh / 0x5FB7]
.> _setjmp(0xBEBBAC30, 0xBEBBAC94, ...) [libc-2.5.so / 0x28E80]
.> main(0x1, 0xBEBBAC94, ...) [ssh / 0x6D00]
. > 0x00005FB7(0x4C64FF4, 0x401BCE0, ...) [ssh / 0x5FB7]
. > sanitise_stdfd(0xBEBBAC90, 0x4B102C8, ...) [ssh / 0x30420]
==================================================================
Thus, direct children of "(below main)" are
0x00015DE0
__cxa_atexit
__libc_csu_init
_setjmp
main
...
Seems to be quite perfect for me.
Or am I missing something here?
Josef
PS: Julian, it would be nice to get rid of the artificial
"(below main)" for tools like callgrind. I do not see
any need here, and it potentially obscures information.
Can we make it an tool option?
>
> -Andi
>
>
>
|
|
From: Nicholas N. <nj...@cs...> - 2007-04-03 22:04:27
|
On Tue, 3 Apr 2007, Josef Weidendorfer wrote: > PS: Julian, it would be nice to get rid of the artificial > "(below main)" for tools like callgrind. I do not see > any need here, and it potentially obscures information. > Can we make it an tool option? Julian and I discussed this just the other day. There's already a --show-below-main option, but it's not implemented quite right. I plan to fix it as part of my Massif-update work. Nick |
|
From: Ashley P. <as...@qu...> - 2007-04-04 19:58:16
|
On Fri, 2007-03-30 at 13:10 +0200, Josef Weidendorfer wrote: > On Friday 30 March 2007, Ashley Pittman wrote: > > Josef Weidendorfer wrote: > > > On Thursday 22 March 2007, Fabian Wein wrote: > > >> Hello, > > >> > > >> is there a way to make a trace of the program run using > > >> valgrind/callgrind? > > > > > > You should state what kind of trace you want. > > > > > > E.g. you can get a call tree trace with > > > valgrind --tool=callgrind --ct-verbose=1 ... > > > > > > > That is truly awesome! It would benefit from strace like command line > > options and possible a cleaner output format but I can see it being very > > useful nevertheless. > > What about making a new tool out of it? > It really would be _especially_ nice to print the function parameters with > correct types, using DWARF debug info. You mean the "resource alloc/dealloc checker" Nick added to the projects page last week? Ltrace *almost* allows you to do things like this and solves the parameter type problem by looking up the sizes in a configuration file. Ashley, |
|
From: Nicholas N. <nj...@cs...> - 2007-04-04 22:05:56
|
On Wed, 4 Apr 2007, Ashley Pittman wrote: >> What about making a new tool out of it? >> It really would be _especially_ nice to print the function parameters with >> correct types, using DWARF debug info. > > You mean the "resource alloc/dealloc checker" Nick added to the projects > page last week? Hmm, there are similarities, but I see those as two different tools. The resource alloc/dealloc checker keeps track of the "tokens" returned by an "alloc" functions and checks if they are deallocated. The function entry/exit trace alone does not give you that. (Well, if you print the args you could maybe work it out, but painfully.) Nick |