|
From: Emilio C. <er...@gm...> - 2011-09-09 22:26:16
|
Hi Josef, sorry for my delay in answering you :( So there must be something wrong with the --ct-verbose=1 output you got. Yes, probably because you do not show PLT, so if you have this flow 1) start function a() 2) return function a() and go in a PLT 3) start function b() You should print this: > a() > PLT() > > b() But if you print: > a () > > b() So you can think (erroneously) that b() is called from a(). So, am I right that if you select strlen in kcachegrind, you do not see > any callees there, too? Yes, you are right. Can you check if objdump sees some symbol at offset 74e in ld.so.13 ? Output of: objdump -d /lib/i386-linux-gnu/ld-2.13.so --start-address=0x074e Here: http://www.ercoppa.org/include/files/dump.log I have improved my code based on your suggestions and callgrind code. I create a new valgrind tool called TF, when it is ready I integrate its code on my valgrind tool (aprof). I do this because maybe this tool can be used by other users interested understanding function tracing (I see other requests in the past about callgrind logic). The code is here: http://code.google.com/p/aprof/source/browse/#svn%2Fbranches%2Ffunction%2Fvalgrind%2Ftf Or: svn co http://aprof.googlecode.com/svn/branches/function/valgrind/tf I try to comment all the code, sorry for the error, I do my best, I hope I can improve them with time. I have two issues for now: 1) TF does not recognize correctly CALL as RET: i use your logic (i hope) but I can't undestand why TF fail doing this compared with callgrind, for example see this two log: TF: http://pastebin.com/jybKDd8D Callgrind: http://pastebin.com/8B1ynfmg If you see callgrind log, almost at the end, there are different prints like "No match found BB(XXX); RET converted in CALL XXX". I insert this prints both on callgrind code and on TF code. But TF does not print the same :( I really do not understand why, maybe it's a little mistake in my code or I miss something in your logic :( 2) For now TF does not manage signal handlers: I am trying to understand your code (I have not spent much time on this part, because these days I have to prepare an exam :( ). You say: I put a marker > into the shadow stack if I see a signal handler being called. This way, > even long jumps out of signal handlers are detectede. But if a signal handler do a long jump, I expect that synchronization of SP fix this problem. Why not? I mean code in setup_bbcc() line 745:749 ( http://code.google.com/p/aprof/source/browse/trunk/valgrind/callgrind/bbcc.c ). Of course with a marker I can assure that all push made inside the signal handler, are correctly pop out. Is this the reason? Sorry for my bad english. Emilio. |