|
From: Josef W. <Jos...@gm...> - 2005-11-18 18:59:20
|
On Friday 18 November 2005 18:23, Julian Seward wrote: > > 1. The redirect/no-redirect decision was made on the basis of > whether the tool overrides malloc or not. This is not a > good criterion -- for example it means the redirection is done > for massif too. Yes. Makes sense. > > 2. It means there are more ways the system can break -- now we > have some tools using these replacement fns and some tools not > using them. And on the other architectures? Don't you have these 2 cases there, too? Or are there no redirections? > To tell the truth I'm not really clear what problem callgrind has > with them. On the one hand, it is a technical one: I have to clearly separate the the uses of non-redirected and redirected addresses of a BB, as instruction addresses appear in the profiling output with callgrind (in contrast to cachegrind). Solvable. Another thing: because of redirection, I can not do jump/call handling at the end of a BB, because the goto target will not always be correct. > They just replace strlen and strcmp when called from > ld.so, but they don't replace the strlen and strcmp in glibc, so > I would not expect them to come very high on the profiles. Still it feels wrong. A profiling tool should run the same code as in reality. Why artificially lower the quality of the result? ld.so's strcmp is used quite often in every symbol resolution. This function can be relevant when looking at startup time of a large program. I just checked: the startup of an empty (about:blank) konqueror window calls into strcmp of ld.so 656,895 times, triggered by 38,095 symbol lookups. > > For meaningful results in the scope of redirections, I had to revert the > > instrument function back to *not* use the noredir_addr. I hope this is > > fine because I switch off chaising. > > Well, it might work, but it's not good. I wonder if there's a > better way to solve this. What is the exact problem here? If we have a redirected BB, is the problem that there can be multiple BBs for this redirected address? Or is this a problem with BB discarding? When a range with a nonredir address (!= redir) of a BB is discarded, I suppose you discard the redirected BB, too? And discard_basic_block_info only gives me the nonredir address? OK, then I would have a problem if a store the BB data by redirected address. The latter case currently is no problem, because of my design error ;-) Currently, I do not really react on BB discards. Josef |