<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jul 10, 2018 at 1:13 PM, Louis Dionne <span dir="ltr"><<a href="mailto:ldionne@apple.com" target="_blank">ldionne@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><br><div><span class="gmail-"><blockquote type="cite"><div>On Jul 10, 2018, at 10:07, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</a>> wrote:</div><br class="gmail-m_-1744977764213608698Apple-interchange-newline"><div><div dir="ltr">I like the idea of `_LIBCPP_HIDE_FROM_ABI`, and I think the first step you proposed sounds reasonable.<div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jul 9, 2018 at 10:33 AM, Louis Dionne via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
1. Everything that is ABI stable is marked with a visibility macro like today (no change here).<br>
2. Everything that is marked with `_LIBCPP_INLINE_VISIBILITY` today is marked with a new `_LIBCPP_HIDE_FROM_ABI` macro instead. This macro can be defined to `__attribute__((__visibility__<wbr>("hidden")))` or to `__attribute__((__visibility__<wbr>("hidden"),internal_linkage))` depending on whether we want to support only use case (1), or both use cases (1) and (2), respectively.</blockquote><div><br></div><div>By ABI stable do you mean exported from the libc++ dylib, or all non-reserved names provided by the library? (2) suggests the former, since entities like std::sort are marked with _LIBCPP_INLINE_VISIBILITY.</div><div>Any entity which a user can reasonably expect to externally instantiate cannot be part of the “hidden ABI”, since marking it with internal linkage will cause linkage failures.</div></div></div></div></div></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>I think we'll be limited to applying `_LIBCPP_HIDE_FROM_ABI` to names which are (A) reserved and (B) cannot be externally instantiated as a member of a class.</div></div></div></div></blockquote><div><br></div></span><div>I mean exported from the libc++ dylib.</div><div><br></div><div>For other readers:</div><div>Regarding linkage failures, Eric and I talked privately and he explained that what he was worried about was a situation such as this one, where a symbol with internal linkage is included in an extern template declaration:</div><div><br></div><div>```</div><div><div>// RUN: %cxx -c %s -o %t.first.o %flags %compile_flags</div><div>// RUN: %cxx -c %s -o %t.second.o -DWITH_MAIN %flags %compile_flags</div><div>// RUN: %cxx -o %t.exe %t.first.o %t.second.o %flags %link_flags</div><div>// RUN: %run</div><div><br></div><div>template <class T></div><div>class Foo {</div><div>public:</div><div> __attribute__((internal_<wbr>linkage)) void bar();</div><div>};</div><div><br></div><div>template <class T></div><div>void Foo<T>::bar() {}</div><div><br></div><div>extern template class Foo<int>;</div><div><br></div><div>#ifdef WITH_MAIN</div><div>int main() {</div><div> Foo<int> f;</div><div> f.bar();</div><div>}</div><div>#else</div><div>template class Foo<int>;</div><div>#endif</div></div><div>```</div><div><br></div><div>This indeed fails to link because the extern template declaration promises that an instantiation will be available in `t.first.o`, but that instantiation ends up having internal linkage and hence not being visible to `t.second.o`. However, if `bar` is marked inline instead, the example compiles because the C++ Standard requires the instantiation to still happen in `t.second.o` even though an extern instantiation is promised, per <a href="http://eel.is/c++draft/temp.explicit#12" target="_blank">http://eel.is/c++draft/<wbr>temp.explicit#12</a>. I don’t think it is ever the case that we use `_LIBCPP_INLINE_VISIBILITY` on a function that is not marked inline in libc++, which is why my proposed solution works in practice. Indeed, if I remove the inline from a function marked as `_LIBCPP_INLINE_VISIBILITY` in a class that is externally instantiated, I do get a linker error when running libc++’s tests.</div><div><br></div><div>So the gist of it is that Eric and I think Eric’s concern is not an issue for libc++, but by not much at all.</div><span class="gmail-"><div><br></div><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This would look something like:<br>
<br>
#ifdef _LIBCPP_NO_INTERNAL_LINKAGE_FO<wbr>R_ABI_UNSTABLE_SYMBOLS<br>
# define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__(<wbr>"hidden")))<br>
#else<br>
# define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__(<wbr>"hidden"),internal_linkage))<br>
#endif<br>
<br>
In the future, we can decide which default behavior we want, but for now, I suggest we stick to what we have right now, which is support for both (1) and (2). It would be fine to change this in the future if we make that decision.<br>
<br></blockquote><div><br></div><div>When we don’t have internal linkage, I suspect we'll want to keep `__always_inline__` as to prevent static libraries from providing each other with incompatible function definitions (I think this could occur?).</div></div></div></div></blockquote><div><br></div></span></div>The idea here is that some people don’t care about interoperability of static libraries (or, equivalently, object files) built with different libc++ headers. And since they don’t care about this, they’d rather not pay the cost of inlining or internal linkage, which is code bloat.</div></div></blockquote><div><br></div><div>The `__always_inline__` is always needed, at least when mixing ABI stable and ABI hidden symbols in a explicitly instantiated template. Here's a reproducer that should fail to link on GCC and Clang:</div><div><a href="https://godbolt.org/g/LLZGjG">https://godbolt.org/g/LLZGjG</a><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div dir="auto" style="word-wrap:break-word"><span class="gmail-HOEnZb"><font color="#888888"><br><div><br></div><div>Louis</div><div><br></div></font></span></div></div></blockquote></div><br></div></div>