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.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
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.
Can you confirm that reverting this path actually fixes the issue? I'm asking because the only test that is executing this script has a REQUIRES: system-darwin line in it.
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.
Ah.. that's possible. REQUIRES needs to be very high up in the file, but I don't know what the exact threshold is