|
From: Josef W. <Jos...@gm...> - 2003-04-15 17:14:19
|
On Tuesday 15 April 2003 17:53, you wrote: > On Tue, 15 Apr 2003, Josef Weidendorfer wrote: > > I copied vg_skin.h to my skin package, and it compiled and runs without > > any problem. It seems that for my skin the interface hasn't changed at > > all. Or should I look out for something? Can you point out what the > > changes are if a skin doesn't need/touches malloc ? > > For your case, I think the only change is that SK_(usage)() has become > SK_(print_usage)() + SK_(print_debug_usage)(). Try giving a bogus command > line option and see if it works. Yes. Thanks for the hint. > Oh, and it's not binary compatible since a lot of needs were removed, but > having recompiled you won't see that. You recently changed the interface version in CVS, so the skin wasn't working without recompilation at all :-) > > The best is that (almost?) no functions of valgrind.so are called now. > > Aside from malloc/free/new/delete, I had the following called from > > clients previously, too: strlen, memchr, strcmp, strchr, memcpy. > > These are all from libc.so now. Seems quite a good change to me. > > Yes. The only ones called now (by default) are those in vg_intercept.c > and vg_libpthread.c. Yes. With a multithreaded test prog, there are a *lot* of calls to VG_(startup), called by ensure_valgrind() in vg_pthreads.c. Looking at the code, I saw that libpthread.so isn't compiled with -fPIC: the call to VG_(startup) does *not* go over a PLT entry, but is a simple call needing relocation. Is this the intended behaviour? On looking at this, I found a bug in V. In valgrind.so, my linker puts the code for "void VG_(sigshutdown_actions) ( void )" from vg_signals.c directly before VG_(startup). And when running the cachegrind skin (your version!), I get ... fl=vg_signals.c fn=??? 1566 609 3 2 609 6 2 fi=??? 0 609 0 0 ... As VG_(sigshutdown_actions) is never called in the test, and vg_signals.c:1566 is the closing brace of that function, there must be a off-by-1 error regarding line debug information lookup, at least for DWARF 2. As the annotated source with my calltree already looked a little weird for some time (at least V 1.9.4 and V 1.9.5), I suppose it's the same bug. I'm a little short of time, but I will look into this. > > > > Apologies to those maintaining patches against the head, I hope you can > > > update and regenerate them without too much trouble. > > > > At least from my side, no trouble at all. > > Thanks again. > > Good, you're welcome. I hope this helps make Calltree's profiling more > accurate. It can make quite a difference with Cachegrind -- all the > malloc/free instructions weren't being profiled before, now they are. Of course this is *very* useful. I thought already about an alternative way, introducing "correction" cost events when calling some function (or using a client request). This is still usefull to somehow "correctify" kernel cost of system calls with some average values. Josef > > N |