> On Feb 28, 2017, at 22:49, Mihai Moldovan <[email protected]> wrote: > >> I don't see the issue using current versions (llvm-3.8+, Xcode 8.x) of >> llvm-dsymutil. I suspect the issue here is that we should be updating the >> driver to use its llvm-dsymutil instead of /usr/bin/dsymutil. > > Well, yes. Your dsymutil is newer - mine's from Xcode 6.2.
Yup. Dated. We definitely can't rely on that puppy. > You're right - llvm-dysmutil-mp-3.* works fine on binaries compiled with our > clang versions, although I haven't tested all combinations, just > llvm-dsymutil-mp-3.x with clang-mp-3.x with x being the same number. > > However, I have noticed that LLVM's dsymutil does not behave like Apple's > dsymutil based upon its version. For instance, the LLVM 3.7-based dsymutil > creates a dSYM file, while 3.8 and newer create a dSYM directory, like Apple's > dsymutil. Yes, 3.8+ is expected to be compatible. Older versions are not the same. I believe Apple started using llvm's dsymutil around the Xcode 8.0 / llvm-3.8 ish timeframe. We should update clang to use the llvm-provided dsymutil for clang-3.8+. Out of curiosity, do you have the issue with clang-3.7 -gdwarf-4 and your dsymutil from dwarfutils-119? >> Please file a ticket. > > Okay, but where exactly? MacPorts or LLVM upstream? MacPorts for me, so we can at least get a fix in on our side. > It's probably best to always > make the driver use the LLVM-based dsymutil version, so uptream? It might be worth an upstream bug as well. I'd like to follow it, so please point me to that one as well.
