search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.86k stars 11.91k forks source link

llvm-symbolizer does not read dsym files outside .app bundles created by Xcode #47234

Open llvmbot opened 4 years ago

llvmbot commented 4 years ago
Bugzilla Link 47890
Version trunk
OS MacOS X
Reporter LLVM Bugzilla Contributor
CC @adrian-prantl,@dwblaikie,@JDevlieghere

Extended Description

When "DWARF with dSYM file" is selected in Xcode project settings > DEBUG_INFORMATION_FORMAT, the dSYM file is created outside the .app bundle.

For Tool.app/Contents/MacOS/Tool, Tool.app.dSYM is created, instead of Tool.app/Contents/MacOS/Tool.dSYM. So llvm-symbolizer cannot read the file and we don't get the file:line info as the docs say.

http://clang.llvm.org/docs/AddressSanitizer.html#symbolizing-the-reports

Adding this feature will make running dsymutil much less painful.

llvmbot commented 4 years ago

Guess it's a bit low priority for us now. To support Ninja and Unix makefiles also, we'd rather have a change in Cmake that runs dsymutil on each executable.

For tools that use Xcode as their primary IDE, llvm-symbolizer being able to read dsym file outside the bundle would be convenient.

I am using a post install script to create an alias near the executable that points to the dsym sitting outside.

llvmbot commented 4 years ago

Xcode, in absence of LLVM (self-built) toolchain, uses atos to give file_name_:line info. atos is very slow, and it hits bad when the binary is over 2.5 GB.

But it's also good at detecting changes to the binaries and saves the unnecessary runs of dsymutil, which we'll have to set up for dozens of binaries if we go the post-build command route, like done here:

https://github.com/llvm/llvm-project/blob/4540d6624838af2b190dfb33802528eb4bfb3fb8/compiler-rt/cmake/Modules/AddCompilerRT.cmake#L707

By having this change in LLVM, we get the best of both worlds using Xcode, faster incremental install times, and faster symbolising after the app quits + filepath:line info.

(still need to figure out a way to avoid touching unedited binaries while using make/ninja)

dwblaikie commented 4 years ago

aprantl,jdevlieghere - this surprises me a bit. I assume Apple's integrated symbolizer story in xcode somehow does the good thing in some cases, but maybe does so by overriding/using a different symbolizer & then if you step outside that you have this non-symbolized experience? Might be nice to fix, but maybe there's more at work here that makes this more niche/less common than it sounds?