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)