<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div dir="auto" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 10, 2018, at 10:07, Eric Fiselier <<a href="mailto:eric@efcs.ca" class="">eric@efcs.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">I like the idea of `_LIBCPP_HIDE_FROM_ABI`, and I think the first step you proposed sounds reasonable.<div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Jul 9, 2018 at 10:33 AM, Louis Dionne via cfe-dev <span dir="ltr" class=""><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank" class="">cfe-dev@lists.llvm.org</a>></span> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
1. Everything that is ABI stable is marked with a visibility macro like today (no change here).<br class="">
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 class="">("hidden")))` or to `__attribute__((__visibility__<wbr class="">("hidden"),internal_linkage))` depending on whether we want to support only use case (1), or both use cases (1) and (2), respectively.</blockquote><div class=""><br class=""></div><div class="">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 class="">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" class=""><br class=""></blockquote><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">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 class=""></div><div>I mean exported from the libc++ dylib.</div><div><br class=""></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 class=""></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 class=""></div><div>template <class T></div><div>class Foo {</div><div>public:</div><div> __attribute__((internal_linkage)) void bar();</div><div>};</div><div><br class=""></div><div>template <class T></div><div>void Foo<T>::bar() {}</div><div><br class=""></div><div>extern template class Foo<int>;</div><div><br class=""></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 class=""></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" class="">http://eel.is/c++draft/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 class=""></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><div><br class=""></div><blockquote type="cite" class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This would look something like:<br class="">
<br class="">
#ifdef _LIBCPP_NO_INTERNAL_LINKAGE_<wbr class="">FOR_ABI_UNSTABLE_SYMBOLS<br class="">
# define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__(<wbr class="">"hidden")))<br class="">
#else<br class="">
# define _LIBCPP_HIDE_FROM_ABI __attribute__((__visibility__(<wbr class="">"hidden"),internal_linkage))<br class="">
#endif<br class="">
<br class="">
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 class="">
<br class=""></blockquote><div class=""><br class=""></div><div class="">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 class=""></div></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.<br class=""><div class=""><br class=""></div><div class="">Louis</div><div class=""><br class=""></div></div></body></html>