<div dir="ltr">> <span style="font-size:12.8px">Is there a reason these symbols *must* have default visibility?</span><div><span style="font-size:12.8px"><br></span></div><div>Yes. These symbols all must have exactly one definition in a C++ program in order to function correctly.</div><div><br></div><div><span style="font-size:12.8px">> lib/Sema/SemaExprCXX.cpp Sema::</span><span style="font-size:12.8px">DeclareGlobalAllocationF<wbr>unctio</span><span style="font-size:12.8px">n</span><br style="font-size:12.8px"></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">The global new/delete are *universally* replaceable. If you have a hidden definition it can't be replaced.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">> </span><span style="font-size:12.8px">lib/CodeGen/ItaniumCXXABI.<wbr>cpp ItaniumRTTIBuilder::</span><span style="font-size:12.8px">BuildTypeI<wbr>nfo</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">This creates typeinfo definitions for the builtin types, such as typeinfo(int). They are automatically emitted by Clang </span></div><div><span style="font-size:12.8px">when it is building libc++abi (<a href="https://godbolt.org/g/OtdstM" target="_blank">https://godbolt.org/g/OtdstM</a>)<wbr>. T</span><span style="font-size:12.8px">ypeinfo equality is fundamentally</span></div><div><span style="font-size:12.8px">based on the uniqueness of symbols. If there are two definitions of a type's typeinfo in a program</span><span style="font-size:12.8px"> things like</span></div><div><span style="font-size:12.8px">dynamic_cast and exception catch blocks may stop working.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">At least that's my understanding of why those symbols are forced to have default visibility.</span></div><div><br></div><div><span style="font-size:12.8px">/Eric</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 4, 2017 at 4:19 PM, James Y Knight via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Typically the way people do this is by passing a --version-script to the linker, which lets you include/exclude symbols as you wish regardless of the visibility attributes.<div><br></div><div>Even more so when building against libstdc++ headers, which forces nearly everything to have default visibility, no matter what.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 4, 2017 at 4:21 PM, Matt Glazar via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I want to statically link libc++ and libc++abi into my ELF DSO (shared<br>
library). (Statically linking avoids incompatibilities with other<br>
libc++/libstdc++/etc. loaded at runtime by other DSO-s.) (My DSO exports<br>
no C++ APIs, imports no C++ APIs, does not throw or catch exceptions<br>
across DSO boundaries, does not require callers to delete returned<br>
pointers, etc.)<br>
<br>
To achieve this, I am using -fvisibility=hidden,<br>
-D_LIBCXXABI_DISABLE_VISIBILIT<wbr>Y_ANNOTATIONS, and<br>
-D_LIBCPP_DISABLE_VISIBILITY_A<wbr>NNOTATIONS (and some other tweaks) when<br>
compiling libc++, libc++abi, and my own code. I build libc++ and libc++abi<br>
as static libraries and link them into my DSO.<br>
<br>
This seems to work well. However, Clang forces some libc++abi symbols to<br>
default visibility. This puts these symbols in my DSO's dynamic export<br>
table. Thus:<br>
<br>
* Linking against my DSO may inadvertently use my DSO's symbols instead of<br>
the symbols you expect (e.g. the system libstdc++'s symbols).<br>
* It also means my DSO's references to its libc++abi symbols may be<br>
replaced at runtime with another DSO's symbols (e.g. the system<br>
libstdc++'s symbols).<br>
<br>
>From what I have found so far, default visibility for libc++abi symbols is<br>
forced in two places in Clang:<br>
<br>
* lib/Sema/SemaExprCXX.cpp Sema::DeclareGlobalAllocationF<wbr>unction<br>
* lib/CodeGen/ItaniumCXXABI.cpp ItaniumRTTIBuilder::BuildTypeI<wbr>nfo<br>
<br>
Is there a reason these symbols *must* have default visibility? I<br>
understand that, in general, typeinfo should have default visibility for<br>
exception handling to function properly. Does an opt-in option to change<br>
the visibility of these symbols (for use cases like mine) sound reasonable?<br>
<br>
Thanks,<br>
<br>
Matthew Glazar<br>
<br>
______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>