Quantcast

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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mihai Moldovan-2
Hi all
Hi Jeremy

Minimal testcase:

<-----snip----->
#include <cstdlib>
#include <iostream>
#include <unordered_set>
#include <type_traits>
#include <string>

int main (int argc, char **argv) {
  if (argc <= 1) {
    std::cerr << "Provide a string." << std::endl;

    return (EXIT_FAILURE);
  }

  std::string input (argv[1]);

  std::unordered_set<std::remove_reference<decltype (input)>::type::value_type> set;

  return (EXIT_SUCCESS);
}
<-----snip----->


Result when compiled with clang++-mp-3.8 -std=c++11 -gdwarf-4 test.cpp -o test -v:

<-----snip----->
clang version 3.8.1 (tags/RELEASE_381/final)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
InstalledDir: /opt/local/libexec/llvm-3.8/bin
 "/opt/local/libexec/llvm-3.8/bin/clang" -cc1 -triple x86_64-apple-macosx10.9.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -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 274.1 -v -dwarf-column-info -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=lldb -resource-dir /opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1 -stdlib=libc++ -std=c++11 -fdeprecated-macro -fdebug-compilation-dir /Users/ionic/src/clang-test -ferror-limit 19 -fmessage-length 228 -stack-protector 1 -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-439d50.o -x c++ test.cpp
clang -cc1 version 3.8.1 based upon LLVM 3.8.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.8/bin/../include/c++/v1
 /usr/local/include
 /opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
 "/opt/local/libexec/llvm-3.8/bin/ld" -demangle -dynamic -arch x86_64 -macosx_version_min 10.9.0 -o test /var/folders/f_/z3_y3gd96td15z4rnkymd5hc0000gn/T/test-439d50.o -lc++ -lSystem /opt/local/libexec/llvm-3.8/bin/../lib/clang/3.8.1/lib/darwin/libclang_rt.osx.a
 "/usr/bin/dsymutil" -o test.dSYM test
warning: {0x0000920a} TAG_formal_parameter:  AT_location( 0x001f0c11 ) didn't have valid function low pc, the location list will be incorrect.
warning: {0x00009218} TAG_formal_parameter:  AT_location( 0x001f0811 ) didn't have valid function low pc, the location list will be incorrect.
warning: {0x00009226} TAG_variable:  AT_location( 0x001efc11 ) didn't have valid function low pc, the location list will be incorrect.
warning: {0x00009234} TAG_variable:  AT_location( 0x001ee811 ) didn't have valid function low pc, the location list will be incorrect.
Assertion failed: (pos->hi_pc >= cu_base_addr), function AppendDebugRanges, file /SourceCache/dwarf_utilities/dwarf_utilities-119/source/DWARFDebugAranges.cpp, line 197.
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: dsymutil command failed due to signal (use -v to see invocation)
<-----snip----->

Is it worthwhile to report that to LLVM upstream? Or not really, since it's a bug in dsymutil, which is Apple's creation?

Xcode's clang doesn't make dsymutil choke, though.



Mihai


signature.asc (902 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mihai Moldovan-2
Actually, this is enough to trigger an assertion failure (albeit a different one):

<-----snip----->
#include <cstdlib>
#include <iostream>

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

  return (EXIT_SUCCESS);
}
<-----snip----->

Assertion failed: (linked_addr_pos != line_table_map.end()), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-119/source/DWARFdSYM.cpp, line 3749.

Tested and reproduced with both clang 3.7 and 3.8.

Unreproducible with Xcode clang.

When compiled with clang 3.9, dsymutil spews out warnings, but *doesn't* trip on an assertion:

warning: {0x00004026} TAG_formal_parameter:  AT_location( 0x001fdc11 ) didn't have valid function low pc, the location list will be incorrect.
warning: {0x00004054} TAG_formal_parameter:  AT_location( 0x00002f91 ) didn't have valid function low pc, the location list will be incorrect.



Mihai


signature.asc (902 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jeremy Huddleston Sequoia
What's the output of this on your system:

   /usr/bin/dsymutil --version

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.

Please file a ticket.

--Jeremy

> On Feb 26, 2017, at 02:51, Mihai Moldovan <[hidden email]> wrote:
>
> Actually, this is enough to trigger an assertion failure (albeit a different one):
>
> <-----snip----->
> #include <cstdlib>
> #include <iostream>
>
> int main (int argc, char **argv) {
> std::cerr << std::endl;
>
> return (EXIT_SUCCESS);
> }
> <-----snip----->
>
> Assertion failed: (linked_addr_pos != line_table_map.end()), function FixReferences, file /SourceCache/dwarf_utilities/dwarf_utilities-119/source/DWARFdSYM.cpp, line 3749.
>
> Tested and reproduced with both clang 3.7 and 3.8.
>
> Unreproducible with Xcode clang.
>
> When compiled with clang 3.9, dsymutil spews out warnings, but *doesn't* trip on an assertion:
>
> warning: {0x00004026} TAG_formal_parameter:  AT_location( 0x001fdc11 ) didn't have valid function low pc, the location list will be incorrect.
> warning: {0x00004054} TAG_formal_parameter:  AT_location( 0x00002f91 ) didn't have valid function low pc, the location list will be incorrect.
>
>
>
> Mihai
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mihai Moldovan-2
On 01.03.2017 04:19 AM, Jeremy Huddleston Sequoia wrote:
> What's the output of this on your system:
>
>    /usr/bin/dsymutil --version

@(#)PROGRAM:dsymutil  PROJECT:dwarfutils-119

(Incidentally matches the path in the program's assertion, I just noticed.)


> 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.


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.


> Please file a ticket.

Okay, but where exactly? MacPorts or LLVM upstream? It's probably best to always
make the driver use the LLVM-based dsymutil version, so uptream?



Mihai


signature.asc (902 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jeremy Huddleston Sequoia

> On Feb 28, 2017, at 22:49, Mihai Moldovan <[hidden email]> 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.


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Mihai Moldovan-2
On 02.03.2017 06:51 AM, Jeremy Huddleston Sequoia wrote:
> Out of curiosity, do you have the issue with clang-3.7 -gdwarf-4 and your dsymutil from dwarfutils-119?

Yes, triggers an assertion as well. I currently don't have 3.6 installed, so
didn't test with that.


> MacPorts for me, so we can at least get a fix in on our side.

https://trac.macports.org/ticket/53673


> It might be worth an upstream bug as well.  I'd like to follow it, so please point me to that one as well.

I put you on CC on the upstream ticket.
https://bugs.llvm.org//show_bug.cgi?id=32116



Mihai



signature.asc (902 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Jeremy Huddleston Sequoia

> On Mar 2, 2017, at 01:58, Mihai Moldovan <[hidden email]> wrote:
>
> On 02.03.2017 06:51 AM, Jeremy Huddleston Sequoia wrote:
>> Out of curiosity, do you have the issue with clang-3.7 -gdwarf-4 and your dsymutil from dwarfutils-119?
>
> Yes, triggers an assertion as well. I currently don't have 3.6 installed, so
> didn't test with that.
>
>
>> MacPorts for me, so we can at least get a fix in on our side.
>
> https://trac.macports.org/ticket/53673
>
>
>> It might be worth an upstream bug as well.  I'd like to follow it, so please point me to that one as well.
>
> I put you on CC on the upstream ticket.
> https://bugs.llvm.org//show_bug.cgi?id=32116
>
Thanks,

I've got an easy workaround for the 3.8+ case and the upstream fix seems simple as well.

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

--Jeremy


smime.p7s (5K) Download Attachment
Loading...