Setting clang++ 3.7 (maybe also lower versions, but I only tested 3.7, 3.8 and 3.9 on OS X 10.9) to generate DWARFv4 debugging information might crash Apple's Xcode dsymutil.
Minimal example:
#include <cstdlib>
#include <iostream>
int main (int argc, char **argv) {
std::cerr << std::endl;
return (EXIT_SUCCESS);
}
Compile output:
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)
For clang 3.8 and higher, it probably makes sense to change the driver to always use the corresponding llvm-dsymutil (which is behaving in an Apple-compatible way since 3.8.)
3.7 and lower are more complicated: while Apple's dsymutil creates dSYM bundles (directories) by default, llvm-dsymutil 3.7 and lower only support flat dSYM files. Not sure how gdb and lldb handle these.
Should be a simple change to first look for getToolChain().GetProgramPath("llvm-dsymutil") and use it before trying getToolChain().GetProgramPath("dsymutil") in lib/Driver/Tools.cpp
Extended Description
Setting clang++ 3.7 (maybe also lower versions, but I only tested 3.7, 3.8 and 3.9 on OS X 10.9) to generate DWARFv4 debugging information might crash Apple's Xcode dsymutil.
Minimal example:
Compile output:
For clang 3.8 and higher, it probably makes sense to change the driver to always use the corresponding llvm-dsymutil (which is behaving in an Apple-compatible way since 3.8.)
3.7 and lower are more complicated: while Apple's dsymutil creates dSYM bundles (directories) by default, llvm-dsymutil 3.7 and lower only support flat dSYM files. Not sure how gdb and lldb handle these.
Xref: Discussion on the macports-devel mailing list: https://lists.macports.org/pipermail/macports-dev/2017-February/035446.html and continued discussion in March 2017 Xref: MacPorts ticket https://trac.macports.org/ticket/53673