Often users have a crash log an d a .dSYM bundle, but not the original application binary. It turns out that for crash symbolication, we can safely fall back to using the binary inside the .dSYM bundle.
Yep, looks good. It would be nice if we found a dSYM with a Spotlight search (mdfind) if we could look NEXT to the dSYM bundle and see if there is a real binary, and load that. But this is a good first step, and it gets us the source-level information for symbolicating the crash. More advanced crashlog users may want to look at the assembly instructions around the crash site, and for that we need the actual binary.
This change made the Windows test get stuck: http://lab.llvm.org:8014/builders/lldb-x64-windows-ninja/builds/2340
They are now being killed after running for 40 minutes instead of completing in under 2.
Removing the test does fix the issue. I suspect the problem is the ordering of the REQUIRES and RUN lines, but I have not tested it. Regardless, the crashlog changes were the only two changes to LLDB in the first build that got stuck (there was also an llvm change). Please fix/revert this in the next couple of hours as we haven't had a good test run for LLDB on Windows since your change.