Page MenuHomePhabricator

[libc++] Explicitly provide a list of exported symbols for libc++
Needs ReviewPublic

Authored by ldionne on Aug 29 2019, 12:35 PM.

Details

Reviewers
EricWF
Summary

Controlling what symbols are exported using visibility annotations at
the source level doesn't work very well, because those annotations are
non-standard. The annotations differ subtly from compiler to compiler,
and as a result it's difficult to obtain the same ABI using all compilers.
By defining an explicit list of symbols, we control exactly which symbols
are exported in all cases and we can eventually get rid of visibility
annotations in the source.

Note that this commit only provides such explicit control when building
on Apple platforms. Support for Linux will be coming later.

Event Timeline

ldionne created this revision.Aug 29 2019, 12:35 PM

Work on this patch was prompted by the CI breakage on GCC caused by https://reviews.llvm.org/D62868. Because the build bots using GCC are on Linux, and this patch removes -fvisibility=hidden when building on Linux, it will silence the CI failures as a side effect.

However, in the future, we can add a similar list using linker version files for Linux, which should work with both GCC and Clang (because it's linker specific anyway).

ldionne updated this revision to Diff 218148.Aug 30 2019, 12:04 PM

Use some wildcards to make the list work in 32 bit mode, where ptrdiff_t is
int instead of long

I see maintaining an explicit list of exports as an ongoing time sink - are you sure this is the the direction that we want to take?

I see maintaining an explicit list of exports as an ongoing time sink - are you sure this is the the direction that we want to take?

This list only contains symbols that we want to export from the dylib, not all symbols. And we already need to update the ABI list (so it passes the check-cxx-abilist test) whenever we add a new symbol to the dylib. So I think this isn't going to be a huge time sink on top of what we already do, but I could be wrong. On the other hand, it has the benefit that we will be able to remove all visibility annotations from the libc++ sources.

I see maintaining an explicit list of exports as an ongoing time sink - are you sure this is the the direction that we want to take?

We can probably automate the creation of this list. Maybe we could add it to CI?

I see maintaining an explicit list of exports as an ongoing time sink - are you sure this is the the direction that we want to take?

We can probably automate the creation of this list. Maybe we could add it to CI?

I don't think we want to automate it. The very purpose is to have _explicit_ control over symbols that we export. That way, we do not end up exporting symbols that we wish we did not export.

When a vendor exports a symbols from the dylib, it needs to export it for ever.

I think that controlling via annotations is actually very useful. It will actually still be needed to ensure that libc++ continues to build on Windows properly (which really does want the annotations). The annotations being applied there makes it easy to then handle properly on the other platforms as well. Additionally, diffs explicitly call out the interface in the change, which again helps review the changes. Finally, there are some symbols which are synthesized by the compiler and the visibility for those are controlled by means of the annotation on the associated class. This again is far easier to manage with the explicit annotation rather than the explicit export list.