|
From: Josef W. <Jos...@gm...> - 2003-03-21 15:40:52
|
On Friday 21 March 2003 10:42, Nicholas Nethercote wrote:
> I've been thinking about Josef's suggestion about letting the skin decide
> if it wants to use __libc_malloc() or Valgrind's malloc(), and whether to
> wrap them. I think it could be done, although I haven't got around to
> trying it yet. This {mem,str,strn}cpy() checking could be done
> similarly... Memcheck and Addrcheck would use Valgrind's provided
> versions, using a wrapper that checks the args don't overlap, and other
> skins could use the libc versions. Ah, except it seems that glibc doesn't
> define __libc_memcpy the way it does __libc_malloc, which could make
> things tricky.
Hmm...
Doesn't GCC use it's own inline-version of memcpy when optimization is on?
An alternative solution for function wrapping would be not to use the runtime
linker (symbol overwriding, hack with __libc_malloc), but to change
instrumentation of the first BB of the given function, and do a "jmp" into
the valgrind wrapper version if the skin would like to use it.
This avoids the static behaviour of symbol definitions in shared libraries,
and can even be done by valgrind core before calling the instrumentation
function of the skin. Still, in the case of wrapping, the instrumentation
function of the skin should get the replaced jump for further
instrumentation.
> Still, this whole question of "do I use the normal version or Valgrind's
> version of function x()" is worth investigation, and I hope to look into
> it more soon.
In my latest calltree version, I introduced an infrastruction to specify
instrumentation parameters on the basis of a function symbol name.
This would be a good addition to valgrind core, and would come handy
with the above wrapping (wrapper function as parameter dependent on symbol
name).
As the lookup for instrumentation parameters has to be done on instrumentation
of every basic block, this has to be fast. I use a prefix tree for lookup.
This even allows to only specify symbol prefixes, i.e. a star wildcard at the
end.
E.g. say you have set
- parameter A=0 for symbol "foo1",
- parameter A=1 for symbol "foo1bar",
- parameter A=2 for symbol "foo2",
- parameter A=3 for symbol "foo*".
The prefix search tree looks like this:
"foo"
+-- "*": A=3
+-- "1": A=0
+-- "bar": A=1
+-- "2": A=2
e.g. if you have symbol "foobar", it goes down the tree and stops with A=3.
Does it make sense to merge this in some way with the error suppression stuff?
Josef
PS: Nick, could you send me the scripts for the SPEC2000 benchmarks?
I would like to check it with my skin.
>
> N
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Valgrind-developers mailing list
> Val...@li...
> https://lists.sourceforge.net/lists/listinfo/valgrind-developers
|
|
From: Nicholas N. <nj...@ca...> - 2003-03-21 16:28:17
|
On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > Doesn't GCC use it's own inline-version of memcpy when optimization is on? Yes. Not much you can do; the user manual recommends turning off optimisation anyway ;) (Actually, I think it compromises on -O...) > An alternative solution for function wrapping would be not to use the runtime > linker (symbol overwriding, hack with __libc_malloc), but to change > instrumentation of the first BB of the given function, and do a "jmp" into > the valgrind wrapper version if the skin would like to use it. Hey, good idea. I'll have to think about that some more... > In my latest calltree version, I introduced an infrastruction to specify > instrumentation parameters on the basis of a function symbol name. > This would be a good addition to valgrind core, and would come handy > with the above wrapping (wrapper function as parameter dependent on symbol > name). > [...] > Does it make sense to merge this in some way with the error suppression stuff? What do you mean by "instrumentation parameters"? N |
|
From: Josef W. <Jos...@gm...> - 2003-03-21 16:47:41
|
On Friday 21 March 2003 17:15, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > > Does it make sense to merge this in some way with the error suppression > > stuff? > > What do you mean by "instrumentation parameters"? Parameters specified by the user at runtime, which influence the instrumentation added to the basic block(s) of a function. E.g. I support command line options "--fn-recursion<no>=<function>", "--dump-before=<function>", "--fn-skip=<function>", allowing to specify an option multiple times for different functions. When entering a function the first time in a program run, the instrumentation is done. Above parameters can influence the instrumentation of the BB. OK, perhaps it's not the right word, as often only the behaviour of some helper function is changed, called by the instrumentation done. Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-03-23 15:57:29
|
On Fri, 21 Mar 2003, Nicholas Nethercote wrote: > > An alternative solution for function wrapping would be not to use the runtime > > linker (symbol overwriding, hack with __libc_malloc), but to change > > instrumentation of the first BB of the given function, and do a "jmp" into > > the valgrind wrapper version if the skin would like to use it. > > Hey, good idea. I'll have to think about that some more... Hmm, one problem is that it requires glibc to not be stripped, since spotting function entries relies on symbol information being present. I'm not sure whether this is likely or not. Also, there's the issue of whether malloc() gets called before Valgrind gains control, possibly because of static C++ constructors. I've discussed this with Julian before but I cannot remember what the outcome was, so maybe I'm wrong. N |
|
From: Josef W. <Jos...@gm...> - 2003-03-24 13:10:17
|
On Sunday 23 March 2003 16:57, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Nicholas Nethercote wrote: > > > An alternative solution for function wrapping would be not to use the > > > runtime linker (symbol overwriding, hack with __libc_malloc), but to > > > change instrumentation of the first BB of the given function, and do a > > > "jmp" into the valgrind wrapper version if the skin would like to use > > > it. > > > > Hey, good idea. I'll have to think about that some more... > > Hmm, one problem is that it requires glibc to not be stripped, since > spotting function entries relies on symbol information being present. > I'm not sure whether this is likely or not. Symbol information for exported symbols in shared libraries can't be stripped, as the runtime linker has to know about it. This isn't debug information, and thus no problem. Static linking with glibc is another issue - but valgrind doesn't work with static binaries at all. > Also, there's the issue of whether malloc() gets called before Valgrind > gains control, possibly because of static C++ constructors. I've > discussed this with Julian before but I cannot remember what the outcome > was, so maybe I'm wrong. Hmm. malloc() is passing requests to arena_malloc() if not running on the simulated CPU. I still think that wrapping malloc() is a skin issue, and the core only should provide convenience functions for doing this in a simply way... Josef |
|
From: Nicholas N. <nj...@ca...> - 2003-03-24 13:19:32
|
On Mon, 24 Mar 2003, Josef Weidendorfer wrote: > > Hmm, one problem is that it requires glibc to not be stripped, since > > spotting function entries relies on symbol information being present. > > I'm not sure whether this is likely or not. > > Symbol information for exported symbols in shared libraries can't be stripped, > as the runtime linker has to know about it. This isn't debug information, and > thus no problem. Ah, good, so no problem there. > I still think that wrapping malloc() is a skin issue, and the core only should > provide convenience functions for doing this in a simply way... I agree. N |
|
From: Nicholas N. <nj...@ca...> - 2003-03-23 16:03:26
|
On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > In my latest calltree version, I introduced an infrastruction to specify > instrumentation parameters on the basis of a function symbol name. > [snip] > Does it make sense to merge this in some way with the error suppression stuff? By this, I'm guessing you mean: after reading suppressions, if Valgrind translates a function that is mentioned in a suppression, don't instrument it because any errors from it will be suppressed anyway? Two problems with that: (a, minor) you don't get counts of the number of errors suppressed, and (b, major) suppressions rely on calling context, so just considering a function by itself wouldn't work -- errors from it might need to be suppressed if called from function f(), but not if called from function g(). Or maybe I misinterpreted your question... N |
|
From: Josef W. <Jos...@gm...> - 2003-03-24 13:10:16
|
On Sunday 23 March 2003 17:03, Nicholas Nethercote wrote: > On Fri, 21 Mar 2003, Josef Weidendorfer wrote: > > In my latest calltree version, I introduced an infrastruction to specify > > instrumentation parameters on the basis of a function symbol name. > > [snip] > > Does it make sense to merge this in some way with the error suppression > > stuff? > > By this, I'm guessing you mean: after reading suppressions, if Valgrind > translates a function that is mentioned in a suppression, don't instrument > it because any errors from it will be suppressed anyway? No, I didn't thought about any concrete use cases for other skins. It's more about generalizing the idea of suppressions. I think I first have to work it out in my skin and perhaps propose a patch for the core later on. > Two problems with that: (a, minor) you don't get counts of the number of > errors suppressed, and (b, major) suppressions rely on calling context, so Oh. I have to look at the suppression code more deeply :-) Josef > just considering a function by itself wouldn't work -- errors from it > might need to be suppressed if called from function f(), but not if called > from function g(). > > Or maybe I misinterpreted your question... > > N > > > > ------------------------------------------------------- > This SF.net email is sponsored by:Crypto Challenge is now open! > Get cracking and register here for some mind boggling fun and > the chance of winning an Apple iPod: > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |