Summary:
This change changes the build to use -fvisibility=hidden
The exports this patch removes are symbols that should have never been exported
by the dylib in the first place, and should all be symbols which the linker
won't de-duplicate across SO boundaries, making them safe to remove.
After this change, we should be able to apply `_LIBCPP_HIDDEN` to the versioning namespace without changing the export lists.
Reviewers: ldionne, mclow.lists
Reviewed By: ldionne
Subscribers: smeenai, mgorny, libcxx-commits
Differential Revision: https://reviews.llvm.org/D53868
llvm-svn: 345664
Summary:
When building with -fvisibility=hidden, some symbols do not get exported from
libc++.dylib. This means that some entities are not explicitly given default
visibility in the source code, and that we rely on the fact -fvisibility=default
is the default. This commit explicitly gives default visibility to those
symbols to avoid being dependent on the command line flags used.
The commit also remove symbols from the dylib -- those symbols do not
actually need to be exported from the dylib and this should not be an
ABI break.
Finally, in the future, we may want to mark the whole std:: namespace as
having hidden visibility (to switch from opt-out to opt-in), in which
case the changes done in this commit will be required.
Reviewers: EricWF
Subscribers: mgorny, christof, dexonsmith, libcxx-commits
Differential Revision: https://reviews.llvm.org/D52662
llvm-svn: 345260
Summary:
They are introduced in r338479; their Linux ABI changes are recorded in r338486.
TODO: Record the Mac OS X ABI changes.
Reviewers: EricWF
Reviewed By: EricWF
Subscribers: christof, ldionne, libcxx-commits, cfe-commits
Differential Revision: https://reviews.llvm.org/D52391
llvm-svn: 342810
r333467 updated the symbols exported by libc++.so/dylib by changing
the ODR usage of __uncaught_exception/__uncaught_exceptions. This
should not be a breaking change.
llvm-svn: 333481
Patch from Eddie Elizondo. Reviewed as D37830 (https://reviews.llvm.org/D37830).
On MacOSX the following program:
struct S { virtual void f() = delete; };
int main() { new S; }
Fails with the following error:
Undefined symbols for architecture x86_64:
"___cxa_deleted_virtual"
This adds a fix to export the needed symbols.
Test:
> lit -sv test/libcxx/language.support/cxa_deleted_virtual.pass.cpp
> Testing Time: 0.21s
> Expected Passes : 1
llvm-svn: 313500
When building libc++ with hidden visibility, we want explicit template
instantiations to export members. This is consistent with existing
Windows behavior, and is necessary for clients to be able to link
against a hidden visibility built libc++ without running into lots of
missing symbols.
An unfortunate side effect, however, is that any template methods of a
class with an explicit instantiation will get default visibility when
instantiated, unless the methods are explicitly marked inline or hidden
visibility. This is not desirable for clients of libc++ headers who wish
to control their visibility, and led to PR30642.
Annotate all problematic methods with an explicit visibility specifier
to avoid this. The problematic methods were found by running
https://github.com/smeenai/bad-visibility-finder against the libc++
headers after making the _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS change. The
methods were marked with the new _LIBCPP_METHOD_TEMPLATE_IMPLICIT_INSTANTIATION_VIS
macro, which was created for this purpose.
It should be noted that _LIBCPP_EXTERN_TEMPLATE_TYPE_VIS was originally
intended to expand to default visibility, and was changed to expanding
to default type visibility to fix PR30642. The visibility macro
documentation was not updated accordingly, however, so this change makes
the macro consistent with its documentation again, while explicitly
fixing the methods which resulted in that PR.
Differential Revision: https://reviews.llvm.org/D29157
llvm-svn: 296731
D29157 will make explicit template instantiations expand to default
visibility, at which point these method templates will need to be
explicitly marked hidden visibility to avoid leaking into other DSOs.
Unfortunately, because of clang PR32114, they must be marked inline (in
conjunction with `-fvisibility-inlines-hidden`) to actually hide them,
since clang doesn't respect the hidden visibility annotation.
Since this involves an ABI change, mark these methods inline in a
separate change, so that the ABI changes can be reviewed separately and
verified to be safe.
Differential Revision: https://reviews.llvm.org/D30523
llvm-svn: 296729
This patch implements changes to allow _LIBCPP_ASSERT to throw on failure
instead of aborting. The main changes needed to do this are:
1. Change _LIBCPP_ASSERT to call a handler via a replacable function pointer
instead of calling abort directly. Additionally this patch implements two
handler functions, one which aborts and another that throws an exception.
2. Add _NOEXCEPT_DEBUG macro for disabling noexcept spec on function which
contain _LIBCPP_ASSERT. This is required in order to prevent assertion
failures throwing through a noexcept function. This macro has no effect
unless _LIBCPP_DEBUG_USE_EXCEPTIONS is defined.
Having a non-aborting _LIBCPP_ASSERT is very important to allow sane testing of
debug mode. Currently we can only have one test case per file, since the test
case will cause the program to abort. Testing debug mode this way would require
thousands of test files, most of which would be 95% boiler plate. I don't think
this is a feasible strategy. Fortunately using a throwing debug handler solves
these issues.
Additionally this patch rewrites the documentation for debug mode.
llvm-svn: 290651
This patch does two seperate things. First it adds a file called
"__libcpp_version" which only contains the current libc++ version
(currently 4000). This file is not intended for use as a header. This file
is used by Clang in order to easily determine the installed libc++ version.
This allows Clang to enable/disable certain language features only when the
library supports them.
The second change is the addition of _LIBCPP_LIBRARY_VERSION macro, which
returns the version of the installed dylib since it may be different than
the headers.
llvm-svn: 285382
Summary:
This patch turns on `-fvisibility-inlines-hidden` when building the dylib. This is important so that libc++.dylib doesn't accidentally export inline-functions which are ODR used somewhere in the dylib.
On OS X this change has no effect on the current ABI of the dylib. Unfortunately on Linux there are already ~20 inline functions which are unintentionally exported by the dylib. Almost all of these are implicitly generated destructors. I believe removing these function definitions is safe because every "linkage unit" which uses these functions has its own definition, and therefore shouldn't be dependent on libc++.dylib to provide them.
Also could a FreeBSD maintainer comment on the ABI compatibility of this patch?
Reviewers: mclow.lists, emaste, dexonsmith, joker-eph-DISABLED, jroelofs, danalbert, mehdi_amini, compnerd, dim
Subscribers: beanz, mgorny, cfe-commits, modocache
Differential Revision: https://reviews.llvm.org/D25593
llvm-svn: 285101
Summary:
This patch implements the library side of P0035R4. The implementation is thanks to @rsmith.
In addition to the C++17 implementation, the library implementation can be explicitly turned on using `-faligned-allocation` in all dialects.
Reviewers: mclow.lists, rsmith
Subscribers: rsmith, cfe-commits
Differential Revision: https://reviews.llvm.org/D25591
llvm-svn: 284206
Louis Dionne