This would be useful for JIT compilers. These pages have some more discussion: http://tirania.org/blog/archive/2007/Jun-29.html http://idea.opensuse.org/content/ideas/valgrind-support-for-mono The first link has a patch which I've attached to this bug. The patch isn't very clean, but it's a starting point.
Created attachment 36062 [details] starting point patch
Created attachment 36063 [details] test A test. As is, it prints a stack trace with ??? in it. But if notify_jit_function() has the client request added to it, it'll print a nicer stack trace.
Created attachment 57659 [details] WIP Updated patch that integrates into the API a little differently. Also fixes an off-by-one error in the binary search, and lets you deregister JIT code. I'm using this to get cachegrind & callgrind results for SpiderMonkey generated code, but right now only cachegrind is giving back meaningful results.
Callgrind relates its counter arrays to ELF objects, and tries to reuse these counters if a shared library is unmapped and remapped on to a different address. This does not work nicely with code generated in anonymous memory, ie. that should be a special case. Another issue is that Callgrind relates hit/miss counters also per guest instruction. So, if the same JavaScript code is translated multiple times, Callgrind will print out a lot of different instruction addresses for the same JavaScript source (with --dump-instr=yes). But as KCachegrind can not show machine code annotation here anyway, it does not really matter.
Will this RFE be implemented some day? It would be extremely useful for users of LuaJIT and other folks using some JIT compiled code.
Created attachment 158504 [details] Majorly revised and improved patch Here's a revised and improved patch that I have used recently for profiling webassembly applications running on SpiderMonkey. It's still not particularly sophisticated, but works well enough to be useful. It retains the basic design of earlier versions of the patch, in that it stands outside the per-object DebugInfo mechanism used for AOT code. Hence it is localised complexity that does not impact the existing mechanisms.
Created attachment 158505 [details] Majorly revised and improved patch, take 2 (with debug printing removed)
Hi. Julian's latest patch still applies and works on today's valgrind. Thanks for this Julian. I was able to cachegrind our JIT and assign names to our dynamically compiled code ranges and view them in kcachegrind. Before, the JITted code would be clumped into the `???` record in the output file, which was rendered as a `(unknown)` in kcachegrind. (I spoke to a few people in #valgrind-dev IRC and it seems that there is still interest in including this feature in valgrind) One refinement that would be useful (if possible) would be the ability to specify a "dummy" source file to each JITted location so that we can filter by only those using the "source file" grouping feature in kcachegrind. If you use this at the moment, JITted code will be mixed in with all of the other "unknown" code in the profile. By allowing the user to specify their own "source file" (rather than, e.g. hard-coding the source file to "JIT"), it would be possible to give different "source files" to different tiers of a multi-tier JIT, which I think would be useful.