|
From: Greg P. <gp...@ap...> - 2009-02-06 05:00:11
|
On Feb 5, 2009, at 7:44 PM, Nicholas Nethercote wrote: > It also avoids a big problem on Darwin, which has to do with my old > friends, the .dSYM directories. I need to generate and install > vgpreload_memcheck-x86-darwin.so.dSYM alongside > vgpreload_memcheck-x86-darwin.so. The problem is that the .dSYM > directory has a file within it, > vgpreload_memcheck-x86-darwin.so.dSYM/Contents/Resources/DWARF/ > vgpreload_memcheck-x86-darwin.so. > (In case you're wondering, the two .so files aren't the same -- the > top-level one lacks debug info, the one with .dSYM has it.) But if > the .dSYM dir gets renamed during installation to match the renamed > .so, the internal .so name no longer matches and Valgrind's dSYM debug > info reader gets confused. My patch above which avoids the renaming > fixes this problem. We might need to make Valgrind's dSYM locator more robust in the face of renames anyway. I'm not sure what the expected behavior of other tools is when a dSYM directory is renamed. One other way valgrind's dSYM locator can be improved. Built executables include a UUID that is also recorded in the dSYM, and Spotlight indexes dSYMs by that UUID. So Valgrind can use the Spotlight command-line tools to search for a dSYM that matches the executable's UUID. This means the dSYM can be anywhere indexed by Spotlight, not just next to the executable where Valgrind currently looks. % dwarfdump -u --arch=x86_64 /usr/lib/libSystem.B.dylib UUID: 4EA82519-85FD-0407-2381-BEB16342275B (x86_64) % mdfind "com_apple_xcode_dsym_uuids='4EA82519-85FD-0407-2381- BEB16342275B'" /Volumes/precious/cvs/Libc/libSystem.B.dylib.dSYM -- Greg Parker gp...@ap... Runtime Wrangler |