clang: use llvm-dsymutil

[Ionic (Mihai Moldovan)]

Compiling a simple test program with clang-3.7 (maybe even clang-3.6, but I have only tested with 3.7, 3.8 and 3.9) or higher on 10.9 with DWARFv4 debugging information leads to a assertion failures when Apple's /usr/bin/dsymutil is invoked.

Minimal example:

#include <cstdlib>
#include <iostream>

int main (int argc, char **argv) {
  std::cerr << std::endl;

  return (EXIT_SUCCESS);
}

Example output of clang-3.7:

ionic@nopileos~/src/clangtest% clang++-mp-3.7 -std=c++11 -gdwarf-4 test.cpp -o test -v
clang version 3.7.1 (tags/RELEASE_371/final)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
 "/opt/local/libexec/llvm-3.7/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name test.cpp -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -target-linker-version 241.9 -v -gdwarf-4 -dwarf-column-info -resource-dir /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1 -stdlib=libc++ -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/ionic/src/clangtest -ferror-limit 19 -fmessage-length 228 -stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.9.0 -fencode-extended-block-signature -fcxx-exceptions -fexceptions -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o /var/folders/f_/z3_y3gd96td15z4rnkymd5hc0000gn/T/test-d46436.o -x c++ test.cpp
clang -cc1 version 3.7.1 based upon LLVM 3.7.1 default target x86_64-apple-darwin13.4.0
ignoring nonexistent directory "/usr/include/c++/v1"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/libexec/llvm-3.7/bin/../include/c++/v1
 /usr/local/include
 /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-3.7/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -o test /var/folders/f_/z3_y3gd96td15z4rnkymd5hc0000gn/T/test-d46436.o -lc++ -lSystem /opt/local/libexec/llvm-3.7/bin/../lib/clang/3.7.1/lib/darwin/libclang_rt.osx.a
 "/usr/bin/dsymutil" -o test.dSYM test
Assertion failed: (linked_addr_pos != line_table_map.end()), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-119/source/DWARFdSYM.cpp, line 3749.
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: dsymutil command failed due to signal (use -v to see invocation)

Older systems are probably affected on an even greater scale.

Using Xcode's clang does not generate debugging symbols that make Xcode's dsymutil crash.

We should change the driver to use llvm-dsymutil, at least from clang-3.8 onwards, as llvm-dsymutil 3.8+ is compatible with Apple's dsymutil.

It's unclear what to do with clang-3.7 and below, since llvm-dsymutil 3.7- creates dSYM files by default, while Apple's dsymutil always create a dSYM directory by default. llvm-dsymutil 3.7- does not support creating dSYM bundles.

[jeremyhu (Jeremy Huddleston Sequoia)]

The way cfe finds the tool makes this an easy change. We just need to drop a symlink from dsymutil to llvm-dsymutil in the toolchain directory (eg: /opt/local/libexec/llvm-devel/bin)

[Ionic (Mihai Moldovan)]

That's great news! Just adding a symlink is little maintenance work.

3.7 and earlier might be a bit tricky. As a workaround, I suggest you try this to see if it causes the 3.7 driver to use llvm-3.9's dsymutil:

sudo ln -s /opt/local/bin/llvm-dsymutil-mp-3.9 /usr/local/bin/dsymutil

(Answering here instead of on the mailing list.) Yes, that works. Also with ${prefix}/bin.

I have found a tiny bug in llvm-dsymutil (I think), but that probably won't cause any harm:

% rm -rf test.dSYM; touch test.dSYM
% clang++-mp-3.7 -std=c++11 -gdwarf-4 test.cpp -o test -v
[...]
 "/opt/local/bin/dsymutil" -o test.dSYM test
error: cannot create directory test.dSYM/Contents/Resources/DWARF: Not a directory
clang: error: dsymutil command failed with exit code 1 (use -v to see invocation)

Funnily, the file is also deleted, so a second run will work fine.

Baseline is that it seems to work, though.

More importantly though, this also works:

# ln -sv /opt/local/bin/llvm-dsymutil-mp-3.9 /opt/local/libexec/llvm-3.7/bin/dsymutil
'/opt/local/libexec/llvm-3.7/bin/dsymutil' -> '/opt/local/bin/llvm-dsymutil-mp-3.9'
% clang++-mp-3.7 -std=c++11 -gdwarf-4 test.cpp -o test -v
[...]
 "/opt/local/libexec/llvm-3.7/bin/dsymutil" -o test.dSYM test

[jeremyhu (Jeremy Huddleston Sequoia)]

In 5d35ce10/macports-ports:

llvm-3.[89]: Create a dsymutil symlink, so cfe will use it instead of /usr/bin/dsymutil

Fixes #53673

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@…>

[jeremyhu (Jeremy Huddleston Sequoia)]

In 394ae37a/macports-ports:

llvm-devel: Bump to r296779

Create a dsymutil symlink, so cfe will use it instead of /usr/bin/dsymutil

Fixes #53673

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@…>

[jeremyhu (Jeremy Huddleston Sequoia)]

In 18ddbb8/macports-ports:

llvm-4.0: Bump to 4.0-rc2

Create a dsymutil symlink, so cfe will use it instead of /usr/bin/dsymutil

Fixes #53673

Signed-off-by: Jeremy Huddleston Sequoia <jeremyhu@…>