Page MenuHomePhabricator

[libc++abi] Clean up visibility

Authored by smeenai on Nov 21 2016, 5:21 PM.



Use the libc++abi visibility macros instead of pragmas or using
visibility attributes directly. Clean up redundant attributes on
definitions (where the declarations already have visibility attributes
applied, from either libc++ or libc++abi headers).

Introduce _LIBCXXABI_WEAK as a drive-by cleanup, which matches the
semantics of _LIBCPP_WEAK.

No functional change. Tested by building on Linux before and after this
change and verifying that the list of exported symbols is identical.

Diff Detail


Event Timeline

smeenai updated this revision to Diff 78807.Nov 21 2016, 5:21 PM
smeenai retitled this revision from to [libc++abi] Clean up visibility.
smeenai updated this object.
smeenai added a subscriber: cfe-commits.


Lmk if there's any other tests I should run on this to ensure there's no functional difference.

compnerd edited edge metadata.Dec 5 2016, 10:11 AM

I really like the clean up this does. It removes the unnecessary usage of the GCC pragmas and cleans up the definitions by using the headers more properly.

19 ↗(On Diff #78807)

Please clang-format this declaration.

61 ↗(On Diff #78807)

I think that if you are making this static inline, we should hoist this out into a standalone helper outside of the __cxxabiv1 namespace.

smeenai updated this revision to Diff 80361.Dec 5 2016, 5:48 PM
smeenai edited edge metadata.

Addressing @compnerd's comments

smeenai marked 2 inline comments as done.Dec 5 2016, 5:49 PM
EricWF added inline comments.Dec 29 2016, 9:26 PM
25 ↗(On Diff #80361)

Is this really redundant? There is an #include <CrashReporterClient.h> after it. Is this not going to affect those symbols?

23 ↗(On Diff #80361)


27 ↗(On Diff #80361)


34 ↗(On Diff #80361)

Can we abstract this away to a _LIBCXXABI_NEW_DELETE_VIS macro?

compnerd added inline comments.Jan 6 2017, 8:21 PM
34 ↗(On Diff #80361)

Are operator new and operator delete the only functions that will ever need weak linkage? I think that using a more generic macro would be nicer. _LIBCXXABI_WEAK_LINKAGE perhaps?

smeenai updated this revision to Diff 87362.Feb 6 2017, 9:11 PM
smeenai edited the summary of this revision. (Show Details)

Addressing comments

smeenai added inline comments.Feb 6 2017, 9:15 PM
25 ↗(On Diff #80361)

That's a fair point. I think it's kinda unusual to wrap a header file this way (we don't do it for any other system headers, for example), and the header file in question appears to be Apple-internal, so I don't know if it's necessary. I can leave it in place for just the header file inclusion if you prefer, however.

EricWF accepted this revision.Feb 28 2017, 6:53 PM

LGTM minus inline comments.

@smeenai confirmed that this patch doesn't change the ABI list for libc++abi.dylib using

19 ↗(On Diff #87362)


This revision is now accepted and ready to land.Feb 28 2017, 6:53 PM
smeenai added inline comments.Feb 28 2017, 6:56 PM
19 ↗(On Diff #87362)

That would also require changing the __cxxabi_config.h include to a cxxabi.h include (since that's where _LIBCXXABI_NORETURN is defined). Is that acceptable?

smeenai updated this revision to Diff 90119.Feb 28 2017, 8:04 PM

Addressing inline comment

This revision was automatically updated to reflect the committed changes.