When I asked this question I thought about detecting context-change during execuction, not instrumentation. But now I think I need this at instrumentation time. :)
I implemented a mode in helgrind such that all instrumentation is performed, but no shadow value management (cache and state machine) is done. The difference in performance between this variation of helgrind and nulgrind is about 3x. So, I suppose that these 3x are due to the instrumentation code. Meanwhile there are cases when we can avoid instrumenting large portions of code because it is either trustworthy or we don't care about it and memory locations accessed there. >> At instrumentation time, check if a given instruction is the first of a function according to debug information. Is that reliable? Does valgrind instrument each routine completely before starting another routine (I beg my pardon for my ignorance here). Ideally, I would need to know the name of the instrumented routine inside helgrind's hg_instrument. Is that possible? >> In general, as VG is running machine code, and you probably define "context change" as C/C++/... function changes... What we see in the machine code is enough for me. If one wants more-or-less precise mapping to C/C++ functions he will need to disable all compiler optimizations. Thanks, --kcc On Fri, Feb 22, 2008 at 9:26 PM, Josef Weidendorfer <[EMAIL PROTECTED]> wrote: > > On Friday 22 February 2008, Konstantin Serebryany wrote: > > Hi, > > > > A question similar to the one discussed in 'thread-change callback' thread. > > How can I see context change events (i.e. when some thread enters or > > exits a function)? > > Possibilities: > > * At instrumentation time, check if a given instruction is the first of > a function according to debug information. This way, you get "enter function" > events, but not "exit" events. Instrumenting also every exit can get complex, > and you probably end with something similar to part of Callgrinds > functionality. > > * Extract the according functionality from Callgrind into a core module to > make it usable by every tool. There is a shadow callstack which is > resynchronized with the real one, making this approach quite robust. E.g. > it works with recursion, longjmps etc. > Drawback aside from not-existing module: slowdown because of an > instrumented callback at beginning of every basic block (could be optimized > to do the callback at end of BBs instead at beginning, and only when > changing the context). > > * For specific functions, functions wrappers can be installed. This redirects > jumps to the given function to another one you provide in a shared lib which > will be loaded by valgrind dependent on the tool. Function exits work this > way, as the wrapper has its stack frame on the client stack. Callbacks into > your tool have to be done via client requests from the wrapper. AFAIK, this > has problems with recursion and longjmps. > > In general, as VG is running machine code, and you probably define "context > change" > as C/C++/... function changes, there is not always an exact relation among > them, > and thus sometimes difficult whether a given execution should really trigger > a > context change or not (e.g. with end recursion optimization). > > Josef > > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Valgrind-developers mailing list Valgrind-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-developers
