This is an archive of the discontinued LLVM Phabricator instance.

Install libunwind headers
AbandonedPublic

Authored by iid_iunknown on May 13 2015, 7:11 AM.

Details

Reviewers
compnerd
Summary

The patch forces "make install" for libunwind to install the libunwind headers.

Diff Detail

Repository
rL LLVM

Event Timeline

iid_iunknown retitled this revision from to Install libunwind headers.
iid_iunknown updated this object.
iid_iunknown edited the test plan for this revision. (Show Details)
iid_iunknown added a reviewer: compnerd.
iid_iunknown set the repository for this revision to rL LLVM.
iid_iunknown added a subscriber: Unknown Object (MLST).
asl added a subscriber: asl.May 13 2015, 12:51 PM
logan added a subscriber: logan.Jun 1 2015, 6:19 AM

Unfortunately, if we install the unwind.h from libunwind repository, then clang will no longer to compile ARM programs which is linking with libgcc. This is the reason why it was reverted several month ago.

compnerd edited edge metadata.Jul 22 2015, 9:00 AM

I think that the right approach to this is to unify the unwind.h from libunwind and clang and use the header that clang provides.

Saleem, Logan,

Thank you for your remarks.

Having considered the possibility to unify unwind.h from clang and libunwind, I encountered some differences in the headers making the unification a bit obscure to me. I would greatly appreciate if you could take a look and clarify.

Libunwind has different declarations for ARM EHABI. E.g., there are different _Unwind_Exception structures, __personality_routine function signatures, libunwind also defines some additional constants for ARM EHABI. If these differences are to be reflected in the unified header, the header will need to see the libunwind's _LIBUNWIND_ARM_EHABI macro. This will result in includes cross-dependency between clang and libunwind. Another way is to define own version of _LIBUNWIND_ARM_EHABI in the clang's unwind.h, but this does not look nice either.

My another concern is that, if I get it right, libunwind should work properly with any unwind.h. This might be the clang's unwind.h or, for example, the one from savannah. Similarly to the clang's unwind.h, the savannah's unwind.h does not have different / additional declarations for ARM EHABI that the libunwind needs. Hence use of the libunwind with the unwind.h from savannah is not possible. Would you clarify if there are any plans to support such a possibility, please?

Thank you.

logan added a comment.Jul 28 2015, 5:30 PM

My long-term plan is to make <clang>/lib/Headers/unwind.h have all
essential structs and defines to build libunwind and libc++abi. It will
look similar to the one in <libunwind>/include/unwind.h currently, i.e.
guarding different structs and defines with ifdefs.

Besides, the merged unwind.h should be as standalone as possible. There
should be no external dependencies. That's the reason why the header from
libunwind is still not a drop-in replacement at the moment. Some code
duplication might be necessary. For example, the code in
<libunwind>/include/__libunwind_config.h should be duplicated. However, I
don't think this will be a big problem.

I believe that we should be able to build libunwind and libc++abi with the
unwind.h from gcc. We can add some CMake tests or C++ function overloading
to make sure that both <unwind.h> from clang and gcc are supported (I have
done some preliminary experiments.) However, I don't think we can support
ALL unwind.h from everywhere (including the header from savannah.) As you
have mentioned that several structs for ARM EHABI are missing from that
header. The idea is that <unwind.h> is a part of the compiler toolchain,
thus we should prefer the <unwind.h> comes with the compiler to the one
maintained by ourselves.

As for the schedule, I plan to update the header in
<clang>/lib/Headers/unwind.h after the release of LLVM 3.7. So that
<clang>/lib/Headers/unwind.h and <libunwind>/include/unwind.h will keep in
sync in 3.8 release. After the release of 3.8 branch, I am going to remove
the header from libunwind repository. In case that a libunwind user does
not have a latest copy of <unwind.h>, he/she can simply copy the file from
<clang>/lib/Headers.

Hope this clarifies my plan. Feel free to let me know if you have any
questions.

Sincerely,
Logan

iid_iunknown abandoned this revision.Dec 28 2016, 6:00 AM