[cfe-dev] Statically linking libc++/libc++abi (ELF)

[Matt Glazar via cfe-dev]

> The global new/delete are *universally* replaceable. If you have a
>hidden definition it can't be replaced.

If the user specifies -fvisibility=hidden, aren't they saying they
explicitly don't want a replaceable version?

> Typeinfo equality is fundamentally based on the uniqueness of symbols.
>If there are two definitions of a type's typeinfo in a program things
>like dynamic_cast and exception catch blocks may stop working.

I suspected that, but I recall seeing a fallback path in case the
uniqueness guarantee isn't met. Maybe I misread.

But if I specify __attribute__((visibility("hidden"))), another DSO
shouldn't reference the type (with dynamic_cast or catch()), so shouldn't
hidden visibility be allowed?

-----Original Message-----
From: Eric Fiselier <eric at efcs.ca>
Date: Saturday, January 7, 2017 at 5:45 AM
To: James Y Knight <jyknight at google.com>
Cc: Matt Glazar <strager at fb.com>, Saleem Abdulrasool <abdulras at fb.com>,
"cfe-dev at lists.llvm.org" <cfe-dev at lists.llvm.org>
Subject: Re: [cfe-dev] Statically linking libc++/libc++abi (ELF)

>> Is there a reason these symbols *must* have default visibility?
>
>Yes. These symbols all must have exactly one definition in a C++ program
>in order to function correctly.
>
>
>> lib/Sema/SemaExprCXX.cpp Sema::DeclareGlobalAllocationFunction
>
>
>
>The global new/delete are *universally* replaceable. If you have a hidden
>definition it can't be replaced.
>
>
>> lib/CodeGen/ItaniumCXXABI.cpp ItaniumRTTIBuilder::BuildTypeInfo
>
>
>This creates typeinfo definitions for the builtin types, such as
>typeinfo(int). They are automatically emitted by Clang
>when it is building libc++abi (https://godbolt.org/g/OtdstM
><https://urldefense.proofpoint.com/v2/url?u=https-3A__godbolt.org_g_OtdstM
>&d=DgMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=D3cny9QlpKbXpBEOg79oLg&m=4SmOxBnsGsWD
>NK4otOA_W9yTKnt1H1ABUOFLx0F9KHo&s=6La8y35Gu4iIwHHC0xTQKqmnUcSNZTRe7pGYKUPo
>SOI&e=>).
> Typeinfo equality is fundamentally
>based on the uniqueness of symbols. If there are two definitions of a
>type's typeinfo in a program things like
>dynamic_cast and exception catch blocks may stop working.
>
>
>At least that's my understanding of why those symbols are forced to have
>default visibility.
>
>
>/Eric
>
>
>On Wed, Jan 4, 2017 at 4:19 PM, James Y Knight via cfe-dev
><cfe-dev at lists.llvm.org> wrote:
>
>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.
>
>
>Even more so when building against libstdc++ headers, which forces nearly
>everything to have default visibility, no matter what.
>
>
>On Wed, Jan 4, 2017 at 4:21 PM, Matt Glazar via cfe-dev
><cfe-dev at lists.llvm.org> wrote:
>
>I want to statically link libc++ and libc++abi into my ELF DSO (shared
>library). (Statically linking avoids incompatibilities with other
>libc++/libstdc++/etc. loaded at runtime by other DSO-s.) (My DSO exports
>no C++ APIs, imports no C++ APIs, does not throw or catch exceptions
>across DSO boundaries, does not require callers to delete returned
>pointers, etc.)
>
>To achieve this, I am using -fvisibility=hidden,
>-D_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS, and
>-D_LIBCPP_DISABLE_VISIBILITY_ANNOTATIONS (and some other tweaks) when
>compiling libc++, libc++abi, and my own code. I build libc++ and libc++abi
>as static libraries and link them into my DSO.
>
>This seems to work well. However, Clang forces some libc++abi symbols to
>default visibility. This puts these symbols in my DSO's dynamic export
>table. Thus:
>
>* Linking against my DSO may inadvertently use my DSO's symbols instead of
>the symbols you expect (e.g. the system libstdc++'s symbols).
>* It also means my DSO's references to its libc++abi symbols may be
>replaced at runtime with another DSO's symbols (e.g. the system
>libstdc++'s symbols).
>
>From what I have found so far, default visibility for libc++abi symbols is
>forced in two places in Clang:
>
>* lib/Sema/SemaExprCXX.cpp Sema::DeclareGlobalAllocationFunction
>* lib/CodeGen/ItaniumCXXABI.cpp ItaniumRTTIBuilder::BuildTypeInfo
>
>Is there a reason these symbols *must* have default visibility? I
>understand that, in general, typeinfo should have default visibility for
>exception handling to function properly. Does an opt-in option to change
>the visibility of these symbols (for use cases like mine) sound
>reasonable?
>
>Thanks,
>
>Matthew Glazar
>
>_______________________________________________
>cfe-dev mailing list
>cfe-dev at lists.llvm.org
>http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
><https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2D
>bin_mailman_listinfo_cfe-2Ddev&d=DgMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=D3cny9Q
>lpKbXpBEOg79oLg&m=4SmOxBnsGsWDNK4otOA_W9yTKnt1H1ABUOFLx0F9KHo&s=s-TLdtLitV
>c_9VSh0N4PjDoaO6njbkforc2dXnXyRjI&e=>
>
>
>
>
>
>
>
>
>_______________________________________________
>cfe-dev mailing list
>cfe-dev at lists.llvm.org
>http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
><https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2D
>bin_mailman_listinfo_cfe-2Ddev&d=DgMFaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=D3cny9Q
>lpKbXpBEOg79oLg&m=4SmOxBnsGsWDNK4otOA_W9yTKnt1H1ABUOFLx0F9KHo&s=s-TLdtLitV
>c_9VSh0N4PjDoaO6njbkforc2dXnXyRjI&e=>
>
>
>
>
>
>