Version: (using Devel) OS: OS X Installed from: Compiled sources dsymutil is so freaking slow that we can't actually use it without slowing down our automated build and test cycle so much that it's not much use. This means our buildbots have no line numbers in valgrind output, which means that our developers have trouble using it. Since apple has shown no interest in speeding up dsymutil, valgrind may have to bite the bullet and parse the debug info out of .o files for it to be useful for large projects on the mac.
Breakpad is being enhanced to read DWARF data from .o files when no .dSYM is present, too.
I think bug 197928 is the most promising way to fix this. Dan, are you happy if I mark this as a duplicate of bug 197928?
Sadly, no. It does not solve the cycle time problem in the case where an error is occuring. (Making dsymutil lazy would be better than a poke in the eye with a sharp stick, but it's not a fix, and this is not a duplicate bug.)
Won't it help a lot, though? Presumably you're only getting small numbers of errors reported? Or are you suppressing a lot of them (in which case laziness won't help)?
Won't help a bit. Once the first error happens, our cycle time will balloon to longer than the attention span of developers, and bugs will start piling up, never to be cleared. And yes, we have tons of suppressions.
Is dsymutil open source? If so, it would be perhaps informative to know what it's doing, that takes so long.
I don't think it is. Once breakpad implements this feature, though, presumably you could follow their lead without much trouble.
dsymutil is unfortunately not open-source, but Apple gdb is, and it handles this. Breakpad is also open-source and has a developer currently looking at this problem.