[libcxx] By default, do not use internal_linkage to hide symbols from the ABI

[ldionne]

Summary

This led to symbol size problems in Chromium, and we expect this may be
the case in other projects built in debug mode too. Instead, unless users
explicitly ask for internal_linkage, we use always_inline like we used to.

In the future, when we have a solution that allows us to drop always_inline
without falling back on internal_linkage, we can replace always_inline by
that.

Note that this commit introduces a change in contract for existing libc++
users: by default, libc++ used to guarantee that TUs built with different
versions of libc++ could be linked together. With the introduction of the
_LIBCPP_HIDE_FROM_ABI_PER_TU macro, the default behavior is that TUs built
with different libc++ versions are not guaranteed to link. This is a change
in contract but not a change in behavior, since the current implementation
still allows linking TUs built with different libc++ versions together.

[ldionne]

The intent is for this patch to be cherry-picked onto the LLVM 7 release.

This is a straw man proposal to fix issues raised in https://reviews.llvm.org/D49240. The idea is that in the future, we would probably want the non-internal_linkage case to be the default. By introducing the _LIBCPP_HIDE_FROM_ABI_PER_TU setting, we're setting up libc++ users for the right default (i.e. no insane guarantee of being able to link TUs built with different libc++ versions), without actually changing any behavior for the LLVM 7 release. Once we have a solution that allows us to drop _LIBCPP_ALWAYS_INLINE from _LIBCPP_HIDE_FROM_ABI (in LLVM 8), we can just do it and everybody should see code size improvements, without a crazy increase in the number of symbols (as reported by Chromium). In LLVM8, the few projects that actually need to link TUs built with different libc++ versions can then just define _LIBCPP_HIDE_FROM_ABI_PER_TU to keep today's behavior.

[ldionne]

Update documentation for _LIBCPP_HIDE_FROM_ABI

[lebedev.ri]

I suspect this might deserve a wider discussion. At least cfe-dev, perhaps?

[rnk]

I'd prefer not to do this, since internal_linkage generates smaller, more debuggable code by default. I think the symbol table size increase may be specific to MachO, and it may be possible to work around this by changing ld64 to pool strings for symbols by default. I don't know enough about MachO to say if this is possible.

I also think the symbol table size problem may be limited to "large" users of C++: people with 500+ object files using libc++ in a DSO. I'm more comfortable imposing a cost on these users to ask them to opt in to some setting that disables internal_linkage and always_inline than I am leaving always_inline on by default, which adversely affects all users.

[ldionne]

In D50652#1197775, @rnk wrote:

I'd prefer not to do this, since internal_linkage generates smaller, more debuggable code by default. I think the symbol table size increase may be specific to MachO, and it may be possible to work around this by changing ld64 to pool strings for symbols by default. I don't know enough about MachO to say if this is possible.

I also think the symbol table size problem may be limited to "large" users of C++: people with 500+ object files using libc++ in a DSO. I'm more comfortable imposing a cost on these users to ask them to opt in to some setting that disables internal_linkage and always_inline than I am leaving always_inline on by default, which adversely affects all users.

One thing to keep in mind is that we do not have a solution that allows removing both internal_linkage and always_inline. It's either internal_linkage or always_inline, but you can't get rid of both until we fix some problems with extern template declarations and visibility attributes. What I can do, however, is reverse the default to use internal_linkage, and then have a temporary hook that allows Chromium to stay on always_inline. In the future, we'd remove that hook and the choice would be between internal_linkage and nothing at all.

[rnk]

In D50652#1197780, @ldionne wrote:

One thing to keep in mind is that we do not have a solution that allows removing both internal_linkage and always_inline. It's either internal_linkage or always_inline, but you can't get rid of both until we fix some problems with extern template declarations and visibility attributes. What I can do, however, is reverse the default to use internal_linkage, and then have a temporary hook that allows Chromium to stay on always_inline. In the future, we'd remove that hook and the choice would be between internal_linkage and nothing at all.

It's probably worth it to me to debug and understand that problem. Is there a good explanation of it?

Also, if a user could define _LIBCPP_ABI_UNSTABLE, does this problem still apply? Could we remove the problematic visibility attributes if the ABI is unstable?

[ldionne]

In D50652#1197830, @rnk wrote:

In D50652#1197780, @ldionne wrote:

One thing to keep in mind is that we do not have a solution that allows removing both internal_linkage and always_inline. It's either internal_linkage or always_inline, but you can't get rid of both until we fix some problems with extern template declarations and visibility attributes. What I can do, however, is reverse the default to use internal_linkage, and then have a temporary hook that allows Chromium to stay on always_inline. In the future, we'd remove that hook and the choice would be between internal_linkage and nothing at all.

It's probably worth it to me to debug and understand that problem. Is there a good explanation of it?

http://lists.llvm.org/pipermail/llvm-dev/2018-July/124549.html

This is understood, it just needs more work than we can reasonably expect to get into LLVM 7.

Also, if a user could define _LIBCPP_ABI_UNSTABLE, does this problem still apply? Could we remove the problematic visibility attributes if the ABI is unstable?

I guess in that case, we could simply remove _all_ visibility attributes (and linkage attributes). libc++ may end up exporting more symbols than we want, but defining _LIBCPP_ABI_UNSTABLE would explicitly state that we don't care about that. Doing this is a possibility, but don't think this is the way we want to solve the problem at hand.

[hans]

In D50652#1197775, @rnk wrote:

I'd prefer not to do this, since internal_linkage generates smaller, more debuggable code by default.

IIUC, this is what we had before though, so it's a conservative "revert to safety" approach until a better solution can be found.

I think the symbol table size increase may be specific to MachO, and it may be possible to work around this by changing ld64 to pool strings for symbols by default. I don't know enough about MachO to say if this is possible.

I looked some more at my local build. The sum of object file sizes didn't increase very much, the big growth is for the executable, and there it's mostly the string table as your analysis showed.

As far as I understand, string pooling should work fine for Mach-O; LLVM does it for object files already. And yes, ld64 doesn't do it. I looked at this symbol:

__ZNSt3__1eqERKNS_21__tree_const_iteratorIN7testing11ExpectationEPNS_11__tree_nodeIS2_PvEElEES9_

If I understand correctly that function would previously have been inlined everywhere, but now it occurs 20+ times in the symbol table of base_unittests, and yes it's repeated 20+ times in the string table too :-/

I also think the symbol table size problem may be limited to "large" users of C++: people with 500+ object files using libc++ in a DSO. I'm more comfortable imposing a cost on these users to ask them to opt in to some setting that disables internal_linkage and always_inline than I am leaving always_inline on by default, which adversely affects all users.

Sure, if there's a macro we can use to opt in to get the old inlining behaviour, or maybe even better getting linkonce_odr linkage, I'd be a happy camper. But the cost of just growing the executables this much seems like a real problem for our build infrastructure.

[hans]

Oh, or could we do

-D_LIBCPP_HIDE_FROM_ABI=

and just get regular odr linkage for these functions?

[ldionne]

In D50652#1198885, @hans wrote:

Oh, or could we do

-D_LIBCPP_HIDE_FROM_ABI=

and just get regular odr linkage for these functions?

No, you do need to use _LIBCPP_HIDDEN _LIBCPP_ALWAYS_INLINE because of the issue described in http://lists.llvm.org/pipermail/llvm-dev/2018-July/124549.html. But yeah, Chromium could use this workaround.

[ldionne]

In D50652#1198893, @ldionne wrote:

In D50652#1198885, @hans wrote:

Oh, or could we do

-D_LIBCPP_HIDE_FROM_ABI=

and just get regular odr linkage for these functions?

No, you do need to use _LIBCPP_HIDDEN _LIBCPP_ALWAYS_INLINE because of the issue described in http://lists.llvm.org/pipermail/llvm-dev/2018-July/124549.html. But yeah, Chromium could use this workaround.

Actually, scratch that, it does work. One can either use -D_LIBCPP_HIDE_FROM_ABI=_LIBCPP_HIDDEN _LIBCPP_ALWAYS_INLINE to restore the old behavior, or -D_LIBCPP_HIDE_FROM_ABI= to get odr linkage.

[ldionne]

Add a way to change the default behavior of _LIBCPP_HIDE_FROM_ABI at build time. Also, rename the macro to _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE to align with other ABI-related macros.

[dexonsmith]

libcxx/include/__config

798–804 ↗

(On Diff #160680)

This doesn't leave a user-friendly way of opting out of internal linkage if a vendor decides to turn it on by default. I suggest adding a layer of indirection:

// Elsewhere.
#cmakedefine _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE_BY_DEFAULT

// Here.
#ifndef _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE
#  ifdef _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE_BY_DEFAULT
#    define _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE 1
#  else
#    define _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE 0
#  endif
#endif

#ifndef _LIBCPP_HIDE_FROM_ABI
#  if _LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE
#    define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_INTERNAL_LINKAGE
#  else
#    define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_ALWAYS_INLINE
#  endif
#endif

Then users can set the behaviour with -D_LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE=1 or -D_LIBCPP_ABI_HIDDEN_USE_INTERNAL_LINKAGE=0, overriding the vendor default.

[ldionne]

Allow picking a custom default behavior for vendors, per Duncan's comment.

Also, revert to a better name for the macro.

[thakis]

I haven't read all the messages in these threads, forgive me if someone asked this already. It's a bit weird to me that we have to override this behavior in Chromium while the default is different. Why isn't the executable size blowup we see in chromium a problem for everyone else too? Is the plan to fix ld64's string pooling at the same time as rolling this change out, and this is just a workaround for people who have head libc++ but not head ld64?

[ldionne]

In D50652#1201236, @thakis wrote:

I haven't read all the messages in these threads, forgive me if someone asked this already. It's a bit weird to me that we have to override this behavior in Chromium while the default is different. Why isn't the executable size blowup we see in chromium a problem for everyone else too? Is the plan to fix ld64's string pooling at the same time as rolling this change out, and this is just a workaround for people who have head libc++ but not head ld64?

It's the other way around -- the default behavior introduced in this patch is the one before the internal_linkage change. If you want to opt-in, you can define _LIBCPP_HIDE_FROM_ABI_PER_TU.

As a separate goal, we will (in the future) make things better for the default case, i.e. we will get rid of __always_inline__ too and allow ODR-deduplication.

Does that make sense?

[dexonsmith]

LGTM if thakis is happy.

[ldionne]

If that's possible at all, I would like for the Chromium people to build with this patch applied. The expectation is that we'll cherry-pick this patch onto LLVM 7, and it would suck if that did not solve Chromium's problem for some stupid reason.

[hans]

Oh, or could we do

-D_LIBCPP_HIDE_FROM_ABI=

and just get regular odr linkage for these functions?

No, you do need to use _LIBCPP_HIDDEN _LIBCPP_ALWAYS_INLINE because of the issue described in http://lists.llvm.org/pipermail/llvm-dev/2018-July/124549.html. But yeah, Chromium could use this workaround.

Actually, scratch that, it does work. One can either use -D_LIBCPP_HIDE_FROM_ABI=_LIBCPP_HIDDEN _LIBCPP_ALWAYS_INLINE to restore the old behavior, or -D_LIBCPP_HIDE_FROM_ABI= to get odr linkage.

I tried -D_LIBCPP_HIDE_FROM_ABI= but got lots of link errors (see https://bugs.chromium.org/p/chromium/issues/detail?id=872926#c21).

-D_LIBCPP_HIDE_FROM_ABI=_LIBCPP_HIDDEN _LIBCPP_ALWAYS_INLINE works nicely though.

I also tried applying your patch and verified that works for Chromium. If I understand correctly, without setting LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT, it restores the old behaviour of force inlining.

I think this makes sense for Chromium since it allows us to build without any special flags until we can get ODR linkage, and I think it also makes sense for the 7.0 branch to prevent regressing binary sizes for users of the release.

lgtm

[thakis]

(I defer to Hans)

[hans]

Thanks! Merged to 7.0 in r339882.

[ldionne]

In D50652#1202524, @hans wrote:

Thanks! Merged to 7.0 in r339882.

Now that this has been done, I guess we need to document somewhere in the release notes that the default contract given by libc++ is changing in LLVM 7, right?

[hans]

Yes. But in practice nothing really changed though, right? It's just
going forward that things might break:

"This is a change in contract but not a change in behavior, since the
current implementation still allows linking TUs built with different
libc++ versions together."

libcxx/trunk/CMakeLists.txt

if (FUCHSIA)
   set(DEFAULT_ABI_VERSION 2)
 else()
   set(DEFAULT_ABI_VERSION 1)
 endif()
 set(LIBCXX_ABI_VERSION ${DEFAULT_ABI_VERSION} CACHE STRING "ABI version of libc++.")
 option(LIBCXX_ABI_UNSTABLE "Unstable ABI of libc++." OFF)
 option(LIBCXX_ABI_FORCE_ITANIUM "Ignore auto-detection and force use of the Itanium ABI.")
 option(LIBCXX_ABI_FORCE_MICROSOFT "Ignore auto-detection and force use of the Microsoft ABI.")
+option(LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT "Enable per TU ABI insulation by default. To be used by vendors." OFF)
 set(LIBCXX_ABI_DEFINES "" CACHE STRING "A semicolon separated list of ABI macros to define in the site config header.")
 option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 
 if (NOT LIBCXX_ENABLE_SHARED AND NOT LIBCXX_ENABLE_STATIC)
   message(FATAL_ERROR "libc++ must be built as either a shared or static library.")
 endif()
 
 # ABI Library options ---------------------------------------------------------

 
 # Configuration file flags =====================================================
 if (NOT LIBCXX_ABI_VERSION EQUAL DEFAULT_ABI_VERSION)
   config_define(${LIBCXX_ABI_VERSION} _LIBCPP_ABI_VERSION)
 endif()
 config_define_if(LIBCXX_ABI_UNSTABLE _LIBCPP_ABI_UNSTABLE)
 config_define_if(LIBCXX_ABI_FORCE_ITANIUM _LIBCPP_ABI_FORCE_ITANIUM)
 config_define_if(LIBCXX_ABI_FORCE_MICROSOFT _LIBCPP_ABI_FORCE_MICROSOFT)
+config_define_if(LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT _LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT)
 
 config_define_if_not(LIBCXX_ENABLE_GLOBAL_FILESYSTEM_NAMESPACE _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE)
 config_define_if_not(LIBCXX_ENABLE_STDIN _LIBCPP_HAS_NO_STDIN)
 config_define_if_not(LIBCXX_ENABLE_STDOUT _LIBCPP_HAS_NO_STDOUT)
 config_define_if_not(LIBCXX_ENABLE_THREADS _LIBCPP_HAS_NO_THREADS)
 config_define_if_not(LIBCXX_ENABLE_MONOTONIC_CLOCK _LIBCPP_HAS_NO_MONOTONIC_CLOCK)
 config_define_if_not(LIBCXX_ENABLE_THREAD_UNSAFE_C_FUNCTIONS _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS)
 

libcxx/trunk/docs/BuildingLibcxx.rst

.. option:: LIBCXX_BENCHMARK_NATIVE_STDLIB:STRING
   compare libc++ to libstdc++ by building the benchmark tests against both
   standard libraries.
 
 .. option:: LIBCXX_BENCHMARK_NATIVE_GCC_TOOLCHAIN:STRING
 
   Use the specified GCC toolchain and standard library when building the native
   stdlib benchmark tests.
 
+.. option:: LIBCXX_HIDE_FROM_ABI_PER_TU_BY_DEFAULT:BOOL
+
+  **Default**: ``OFF``
+
+  Pick the default for whether to constrain ABI-unstable symbols to
+  each individual translation unit. This setting controls whether
+  `_LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT` is defined by default --
+  see the documentation of that macro for details.
+
 
 libc++ ABI Feature Options
 --------------------------
 
 The following options allow building libc++ for a different ABI version.
 
 .. option:: LIBCXX_ABI_VERSION:STRING
 

libcxx/trunk/docs/DesignDocs/VisibilityMacros.rst

**_LIBCPP_OVERRIDABLE_FUNC_VIS**
   locally, since `dllimport` indicates the symbol should be bound to a separate
   DLL. All `operator new` and `operator delete` overloads are required to be
   locally overridable, and therefore must not be marked `dllimport`. On Windows,
   this macro therefore expands to `__declspec(dllexport)` when building the
   library and has an empty definition otherwise.
 
 **_LIBCPP_HIDE_FROM_ABI**
   Mark a function as not being part of the ABI of any final linked image that
-  uses it, and also as being internal to each TU that uses that function. In
-  other words, the address of a function marked with this attribute is not
-  guaranteed to be the same across translation units.
+  uses it.
 
 **_LIBCPP_HIDE_FROM_ABI_AFTER_V1**
   Mark a function as being hidden from the ABI (per `_LIBCPP_HIDE_FROM_ABI`)
   when libc++ is built with an ABI version after ABI v1. This macro is used to
   maintain ABI compatibility for symbols that have been historically exported
   by libc++ in v1 of the ABI, but that we don't want to export in the future.
 
   This macro works as follows. When we build libc++, we either hide the symbol
   from the ABI (if the symbol is not part of the ABI in the version we're
   building), or we leave it included. From user code (i.e. when we're not
   building libc++), the macro always marks symbols as internal so that programs
   built using new libc++ headers stop relying on symbols that are removed from
   the ABI in a future version. Each time we release a new stable version of the
   ABI, we should create a new _LIBCPP_HIDE_FROM_ABI_AFTER_XXX macro, and we can
   use it to start removing symbols from the ABI after that stable version.
 
+**_LIBCPP_HIDE_FROM_ABI_PER_TU**
+  This macro controls whether symbols hidden from the ABI with `_LIBCPP_HIDE_FROM_ABI`
+  are local to each translation unit in addition to being local to each final
+  linked image. This macro is defined to either 0 or 1. When it is defined to
+  1, translation units compiled with different versions of libc++ can be linked
+  together, since all non ABI-facing functions are local to each translation unit.
+  This allows static archives built with different versions of libc++ to be linked
+  together. This also means that functions marked with `_LIBCPP_HIDE_FROM_ABI`
+  are not guaranteed to have the same address across translation unit boundaries.
+
+  When the macro is defined to 0, there is no guarantee that translation units
+  compiled with different versions of libc++ can interoperate. However, this
+  leads to code size improvements, since non ABI-facing functions can be
+  deduplicated across translation unit boundaries.
+
+  This macro can be defined by users to control the behavior they want from
+  libc++. The default value of this macro (0 or 1) is controlled by whether
+  `_LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT` is defined, which is intended to
+  be used by vendors only (see below).
+
+**_LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT**
+  This macro controls the default value for `_LIBCPP_HIDE_FROM_ABI_PER_TU`.
+  When the macro is defined, per TU ABI insulation is enabled by default, and
+  `_LIBCPP_HIDE_FROM_ABI_PER_TU` is defined to 1 unless overriden by users.
+  Otherwise, per TU ABI insulation is disabled by default, and
+  `_LIBCPP_HIDE_FROM_ABI_PER_TU` is defined to 0 unless overriden by users.
+
+  This macro is intended for vendors to control whether they want to ship
+  libc++ with per TU ABI insulation enabled by default. Users can always
+  control the behavior they want by defining `_LIBCPP_HIDE_FROM_ABI_PER_TU`
+  appropriately.
+
+  By default, this macro is not defined, which means that per TU ABI insulation
+  is not provided unless explicitly overriden by users.
+
 **_LIBCPP_TYPE_VIS**
   Mark a type's typeinfo, vtable and members as having default visibility.
   This attribute cannot be used on class templates.
 
 **_LIBCPP_TEMPLATE_VIS**
   Mark a type's typeinfo and vtable as having default visibility.
   This macro has no effect on the visibility of the type's member functions.
 

libcxx/trunk/include/__config

 #endif
 
 #if __has_attribute(internal_linkage)
 #  define _LIBCPP_INTERNAL_LINKAGE __attribute__ ((internal_linkage))
 #else
 #  define _LIBCPP_INTERNAL_LINKAGE _LIBCPP_ALWAYS_INLINE
 #endif
 
+#ifndef _LIBCPP_HIDE_FROM_ABI_PER_TU
+#  ifndef _LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT
+#    define _LIBCPP_HIDE_FROM_ABI_PER_TU 0
+#  else
+#    define _LIBCPP_HIDE_FROM_ABI_PER_TU 1
+#  endif
+#endif
+
 #ifndef _LIBCPP_HIDE_FROM_ABI
-#  define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_INTERNAL_LINKAGE
+#  if _LIBCPP_HIDE_FROM_ABI_PER_TU
+#    define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_INTERNAL_LINKAGE
+#  else
+#    define _LIBCPP_HIDE_FROM_ABI _LIBCPP_HIDDEN _LIBCPP_ALWAYS_INLINE
+#  endif
 #endif
 
 #ifdef _LIBCPP_BUILDING_LIBRARY
 #  if _LIBCPP_ABI_VERSION > 1
 #    define _LIBCPP_HIDE_FROM_ABI_AFTER_V1 _LIBCPP_HIDE_FROM_ABI
 #  else
 #    define _LIBCPP_HIDE_FROM_ABI_AFTER_V1
 #  endif

libcxx/trunk/include/__config_site.in

 //===----------------------------------------------------------------------===//
 //
 //                     The LLVM Compiler Infrastructure
 //
 // This file is dual licensed under the MIT and the University of Illinois Open
 // Source Licenses. See LICENSE.TXT for details.
 //
 //===----------------------------------------------------------------------===//
 
 #ifndef _LIBCPP_CONFIG_SITE
 #define _LIBCPP_CONFIG_SITE
 
 #cmakedefine _LIBCPP_ABI_VERSION @_LIBCPP_ABI_VERSION@
 #cmakedefine _LIBCPP_ABI_UNSTABLE
 #cmakedefine _LIBCPP_ABI_FORCE_ITANIUM
 #cmakedefine _LIBCPP_ABI_FORCE_MICROSOFT
+#cmakedefine _LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT
 #cmakedefine _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE
 #cmakedefine _LIBCPP_HAS_NO_STDIN
 #cmakedefine _LIBCPP_HAS_NO_STDOUT
 #cmakedefine _LIBCPP_HAS_NO_THREADS
 #cmakedefine _LIBCPP_HAS_NO_MONOTONIC_CLOCK
 #cmakedefine _LIBCPP_HAS_NO_THREAD_UNSAFE_C_FUNCTIONS
 #cmakedefine _LIBCPP_HAS_MUSL_LIBC
 #cmakedefine _LIBCPP_HAS_THREAD_API_PTHREAD

libcxx/trunk/utils/libcxx/test/config.py

def parse_config_site_and_add_features(self, header):
         # Transform each macro name into the feature name used in the tests.
         # Ex. _LIBCPP_HAS_NO_THREADS -> libcpp-has-no-threads
         for m in feature_macros:
             if modules_enabled:
                 define = '-D%s' % m
                 if feature_macros[m]:
                     define += '=%s' % (feature_macros[m])
                 self.cxx.compile_flags += [define]
-            if m == '_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS':
+            if m == '_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS' or \
+               m == '_LIBCPP_HIDE_FROM_ABI_PER_TU_BY_DEFAULT':
                 continue
             if m == '_LIBCPP_ABI_VERSION':
                 self.config.available_features.add('libcpp-abi-version-v%s'
                     % feature_macros[m])
                 continue
             if m == '_LIBCPP_NO_VCRUNTIME':
                 self.config.available_features.add('libcpp-no-vcruntime')
                 continue