This is an archive of the discontinued LLVM Phabricator instance.

[libc++] Re-export libc++abi as a whole instead of using lists
AbandonedPublic

Authored by ldionne on Jun 17 2019, 1:42 PM.

Details

Summary

Since libc++abi properly controls what symbols it exports, it is safe
to just re-export the whole library from libc++. This removes some
coupling between libc++ and libc++abi, and reduces the maintenance
burden of having to maintain a list of symbols in libc++.

As part of this change, the ABI list of symbols exported from libc++ is
updated and does not explicitly contain symbols from libc++abi anymore.
This is okay because those symbols are still reachable for any application
linking against libc++, through the whole-dylib re-export.

Event Timeline

ldionne created this revision.Jun 17 2019, 1:42 PM

Did sym_extract.py remove those symbols from the list, or were they removed manually? Because they should still be present in the libc++ symbol table as imported definitions (I think).

EricWF added inline comments.Jun 17 2019, 2:15 PM
libcxx/lib/abi/x86_64-apple-darwin.v1.abilist
2356

What's up with the filesystem changes?

Did sym_extract.py remove those symbols from the list, or were they removed manually? Because they should still be present in the libc++ symbol table as imported definitions (I think).

sym_extract removed them. They don't appear in the list of symbols anymore, but they should still be available to anyone linking against libc++. I'm checking the details with our linker folks.

ldionne marked 2 inline comments as done.Jun 18 2019, 7:26 AM
ldionne added inline comments.
libcxx/lib/abi/x86_64-apple-darwin.v1.abilist
2356

Those just moved around.

ldionne abandoned this revision.Oct 1 2019, 8:54 AM
ldionne marked an inline comment as done.

Okay, so after speaking to our linker folks a while ago, I decided to drop this.

The reason is that using -lreexport-lc++abi causes the whole library to be re-exported, and ld64 will hoist reexported public dylibs (those that appear in /usr/lib) into applications themselves. In other words, if we used -lreexport-lc++abi, applications linking against /usr/lib/libc++.dylib would start recording a dependency on /usr/lib/libc++abi.dylib directly. This would be new behavior since so far we've successfully hidden libc++abi.dylib behind libc++.dylib on our platform.

Instead, I'll opt for the approach of programmatically generating the list of symbols to be re-exported from libc++.dylib by using nm on the libc++abi.dylib that we link against.

libcxx/lib/libc++abi.v1.exp