This is an archive of the discontinued LLVM Phabricator instance.

[CMake] Cleanup libunwind lookup code.
AbandonedPublic

Authored by logan on Aug 31 2016, 8:41 AM.

Details

Summary

This commit refines the code for libunwind lookup.

First, this commit will always search for libunwind no matter LLVM
unwinder is enabled or not. We have to do so because we need the
modified "unwind.h" from libunwind. (Note: <unwind.h> which is bundled
with clang/gcc is not sufficient.)

Second, this commit removes LIBCXXABI_LIBUNWIND_INCLUDE_INTERNAL and
refines the find_path() function. Now, it looks similar to the one for
libc++.

Third, this commit removes LIBCXXABI_LIBUNWIND_SOURCES since it haven't
been used for a while. (Note: The reference to "libunwind_ext.h" has
been removed since r241993.)

Diff Detail

Event Timeline

logan updated this revision to Diff 69865.Aug 31 2016, 8:41 AM
logan retitled this revision from to [CMake] Cleanup libunwind lookup code..
logan updated this object.
logan added a subscriber: cfe-commits.
logan added a reviewer: asl.Aug 31 2016, 8:42 AM
rengolin edited edge metadata.Aug 31 2016, 8:48 AM

We have to do so because we need the modified "unwind.h" from libunwind. (Note: <unwind.h> which is bundled with clang/gcc is not sufficient.)

So, you need libunwind's sources, even if you're not building or using them, to build libc++abi?

logan added a comment.Aug 31 2016, 8:50 AM

Yes. This is what we have today.

We can either (1) specify the path to libunwind or (2) manually download unwind.h header from libunwind project and place it to include directory.

We can either (1) specify the path to libunwind or (2) manually download unwind.h header from libunwind project and place it to include directory.

That is a horrible dependency... I never hit it because I always test libc++ with libunwind.

Marshall (@mclow.lists), isn't there a better way of doing this? It sounds terrible...

cheers,
--renato

logan added a comment.Aug 31 2016, 9:03 AM

That is a horrible dependency... I never hit it because I always test libc++ with libunwind.

I think the best solution is to move/merge libunwind/include/unwind.h to/with clang/lib/Headers/unwind.h. And, modify the libc++abi code base, so that libc++abi can accept the <unwind.h> bundled with clang or gcc. However, it takes time to reach that point.

asl edited edge metadata.Sep 2 2016, 4:20 AM

I totally agree with Renato. What part of libc++abi requires exactly libunwind's unwind.h, what is the dependency?

logan added a comment.Sep 2 2016, 6:59 AM
In D24084#532724, @asl wrote:

I totally agree with Renato. What part of libc++abi requires exactly libunwind's unwind.h, what is the dependency?

To be specific, we need:

  • Structure Definition: _Unwind_Control_Block (missing from <unwind.h> bundled with clang)
  • Function Declarations: _Unwind_GetLanguageSpecificData(), _Unwind_GetRegionStart(), _Unwind_{Get,Set}{IP,GR}(), _Unwind_{Get,Set}_VRS(), _Unwind_RaiseException()

This is the status quo after libunwind was spun off (or splitted) last year.

logan added a comment.Oct 3 2016, 5:04 AM

Ping. Any further comments? Or, should we duplicate <unwind.h> in multiple repositories?

So, we found this issue with the different unwinds between Clang and libunwind:

https://llvm.org/bugs/show_bug.cgi?id=31035

Is this related?

logan added a comment.Dec 15 2016, 8:54 AM

Hi @rengolin:

Yeah. It is a kind of similar. Another route is to move the code from <libunwind>/include/unwind.h to <clang>/lib/Headers and then ship a shim layer with libc++abi and/or libunwind for old clang.

logan abandoned this revision.Jun 29 2018, 8:24 PM