|
From: Josef W. <Jos...@gm...> - 2003-03-05 23:38:47
|
Hi, I just got a bug/misbehaviour report for cachegrind which is IMHO justified (from Lars Knoll <la...@tr...>). It's about wrong costs of some GLIBC functions when run under cachegrind, namely the ones being reimplemented by valgrind, e.g. malloc, __builtin_new and so on. If you have C++ code with lots of new/delete, the profiled costs are by far underestimated. Aside from signal/thread handling, is there any need that the valgrind-supplied variants have to be called on the simulated CPU when using skins like cachegrind? I would prefer running the original functions and put all the symbols of "vg_clientfuncs.c" into the respective skin. Or am I totally wrong here? Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-03-06 08:50:36
|
On Wed, 5 Mar 2003, Josef Weidendorfer wrote: > It's about wrong costs of some GLIBC functions when run under cachegrind, > namely the ones being reimplemented by valgrind, e.g. malloc, __builtin_new > and so on. > If you have C++ code with lots of new/delete, the profiled costs are by far > underestimated. > > Aside from signal/thread handling, is there any need that the > valgrind-supplied variants have to be called on the simulated CPU when using > skins like cachegrind? > I would prefer running the original functions and put all the symbols of > "vg_clientfuncs.c" into the respective skin. I've wondered about this before. I can see four possible combinations a skin might want: a. ordinary malloc() b. ordinary malloc(), but be notified of new_mem_heap etc. events c. valgrind malloc() d. valgrind malloc(), but be notified of new_mem_heap etc. events Thinking about it some more, the only reason I can think of why valgrind even needs its own malloc() is this: for skins using new_mem_heap etc. events, if they used the ordinary malloc(), they could get two events: one from Valgrind saying "new_mem_heap", and then one when normal malloc() does a mmap() or brk() to actually get the memory. This would be bad. So I think only combinations (a), (c) and (d) above will work. And (c) is the one you want to turn into (a). I guess what would be ideal is if the default is for a skin to use normal malloc() (ie. (a)), but if any of the new_mem_heap, die_mem_heap, etc. events are used by a skin, Valgrind switches to using VG_(malloc) (ie. (d)). But this could be difficult, since symbols are static and the event tracking is set up by the skin once things have started. Can anyone think of a nice way of achieving this? N |