On Saturday 10 September 2011, Emilio Coppa wrote: > > a() > > PLT() > > > b() > > But if you print: > > a () > > > b() > > So you can think (erroneously) that b() is called from a().
You are completely right. The calls into PLT are printed if "--skip-plt=no" is specified. Then, the results should look a lot better. > 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 :( Looks like the places where dl_runtime_resolve() "returns" into the resolved functions. Not sure what you are doing wrong here, but I remember that I had to special-case dl_runtime_resolve. I even have a signature check for the machine code for the case that the runtime linker is stripped... > 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. Yes, of course. While unwinding, it will see the marker, and thus it knows that the signal handler was left. I.e. instead of adding calls to the (separate) call graph of the signal handler, it returns to the regular call graph of the thread. BTW, signal handlers are probably not worth to be handled specially. I already had quite a large number of bug reports because of that. Josef > 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. > ------------------------------------------------------------------------------ Malware Security Report: Protecting Your Business, Customers, and the Bottom Line. Protect your business and customers by understanding the threat from malware and how it can impact your online business. http://www.accelacomm.com/jaw/sfnl/114/51427462/ _______________________________________________ Valgrind-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/valgrind-users
