Summary: | Add a client request to register debug info for code ranges | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Nicholas Nethercote <njn> |
Component: | general | Assignee: | Julian Seward <jseward> |
Status: | CONFIRMED --- | ||
Severity: | wishlist | CC: | amerey, josef.weidendorfer, lupus |
Priority: | NOR | ||
Version: | 3.5 SVN | ||
Target Milestone: | blocking3.6.0 | ||
Platform: | unspecified | ||
OS: | All | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
starting point patch
test WIP Majorly revised and improved patch Majorly revised and improved patch, take 2 (with debug printing removed) |
Description
Nicholas Nethercote
2009-08-11 02:25:01 UTC
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)
|