clang-3.8 crashes dsymutil with -gdwarf-4 on 10.9

[Jeremy Huddleston Sequoia]

> On Feb 28, 2017, at 22:49, Mihai Moldovan <ionic at macports.org> 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.