This is an archive of the discontinued LLVM Phabricator instance.

[libunwind] Support building hermetic static library
ClosedPublic

Authored by phosek on Jan 23 2019, 10:19 AM.

Details

Summary

This is useful when the static libunwind library is being linked into
shared libraries that may be used in with other shared libraries that
use different unwinder. We want to avoid avoid exporting libunwind
symbols in those cases. This achieved by a new CMake option which can be
enabled by libunwind vendors as needed.

The same CMake option has already been added to libc++ and libc++abi in
D55404 and D56026.

Diff Detail

Repository
rL LLVM

Event Timeline

phosek created this revision.Jan 23 2019, 10:19 AM
phosek updated this revision to Diff 183154.Jan 23 2019, 12:28 PM
ldionne added inline comments.Jan 24 2019, 9:13 AM
libunwind/src/CMakeLists.txt
134 ↗(On Diff #183154)

We need to define this when building libunwind? This circular dependency looks like a smell.

phosek marked an inline comment as done.Jan 25 2019, 12:59 AM
phosek added inline comments.
libunwind/src/CMakeLists.txt
134 ↗(On Diff #183154)

Unfortunately yes because libunwind uses operator new (https://github.com/llvm/llvm-project/blob/master/libunwind/src/libunwind.cpp#L125) which definition comes from libc++ and without this define, we get a conflicting declaration error (the implicit declaration provided by the compiler has hidden visibility due to -fvisibility-global-new-delete-hidden but that one that comes from libc++ has default visibility).

mstorsjo added inline comments.Jan 25 2019, 1:07 AM
libunwind/src/CMakeLists.txt
134 ↗(On Diff #183154)

I was under the impression that even if libunwind requires C++ headers to be available, it shouldn't actually require linking to any C++ library (or that this was the design/intention at least); I regularly build it in this setup where my libunwind doesn't link against libc++, as that indeed is a nasty circular dependency. (I only have the checked out libcxx available for libunwind to find headers from.)

This seems to be one of few cases where it's actually invoked as a normal operator new. The other cases that do exist use placement new for invoking the constructor, but avoiding a call to any Standard C++ library function. Would it be better to just adjust this call as well, e.g. into malloc + placement new, to avoid the libcxx linking dependency altogether?

This code seems to be within #ifdef UNW_REMOTE, and I don't see anything within libunwind actually even setting that define, so how are you ending up running into it? (That explains why I haven't noticed.)

mstorsjo added inline comments.Jan 25 2019, 1:17 AM
libunwind/src/CMakeLists.txt
134 ↗(On Diff #183154)

That particular function you linked, unw_create_addr_space_for_task, seems to even lack a return statement, so I'm rather sure that this function isn't in use. IIRC the remote unwinding part of libunwind isn't fully implemented, not built by default, and probably bitrotting.

phosek added inline comments.Jan 25 2019, 8:30 AM
libunwind/src/CMakeLists.txt
134 ↗(On Diff #183154)

I looked into the remote unwinding recently and the current implementation is unfinished and doesn't work (and I don't think it ever worked).

I'd be fine changing this to placement new to eliminate this dependency, but maybe it'd be better to remove this code altogether? Do you have any preference?

mstorsjo added inline comments.
libunwind/src/CMakeLists.txt
134 ↗(On Diff #183154)

I don't mind removing the unused and incomplete remote unwinding code, but that's up to the code owners, @mclow.lists, @EricWF and @ldionne.

phosek added inline comments.Jan 25 2019, 12:11 PM
libunwind/src/CMakeLists.txt
134 ↗(On Diff #183154)

I've created D57251 to switch to using placement new, and D57252 to remove the remote unwinding support altogether. I'd prefer the latter, but either should unblock this change.

phosek updated this revision to Diff 183616.Jan 25 2019, 2:00 PM
phosek marked 6 inline comments as done.

Is this acceptable now that we got rid of the C++ library dependency?

Now that D57262 has landed, would it be fine to land this as well?

ldionne accepted this revision.Jan 28 2019, 12:40 PM
This revision is now accepted and ready to land.Jan 28 2019, 12:40 PM
This revision was automatically updated to reflect the committed changes.