Version: (using Devel) OS: OS X Installed from: Compiled sources Until bug 200214 is fixed, developers who want to avoid hourlong delays running dsymutil on large apps may be tempted to use Apple's gdb to convert addresses to source filename/line number pairs, using the gdb commands file "blah.app" info line *0xFOOBAR where "blah.app" is taken from the valgrind xml log file for the particular warning. However, if the error happens in a shared library, the above commands will try to load the shared library by itself, outside the context of the running app, and gdb might not load the library at the same address. If valgrind also showed the address at which the shared library was loaded, one could presumably use the add-symbol-file gdb command to load the symbols at the proper address.
Doesn't -v do what you want? --21467-- Reading syms from /home/sewardj/VgTRUNK/trunk/Inst/lib/valgrind /vgpreload_core-x86-linux.so (0x4021000) --21467-- Reading syms from /home/sewardj/VgTRUNK/trunk/Inst/lib/valgrind /vgpreload_memcheck-x86-linux.so (0x4024000) Those are the addresses of where the text segment got mapped.
Yes, the bit that's missing is getting it in the xml file. For now I can either grub it out of the text log or bite the bullet and run dsymutil (which might only take 20 minutes rather than the hour I remember).
Created attachment 36453 [details] Draft patch to add load address info to xml file Here's a quick try at the XML change. Does it need to be conditional? Right now, the <load_obj></load_obj> records it emits are at top level, not enclosed in a scope like the <suppcounts> section. That's kind of messy, the final patch might want to do better.
Created attachment 80275 [details] Update the patch to apply to Valgrind r12230