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.
------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT
space for its ease of implementation, lower cost, and increased
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
