Re: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.
>> Yes, that is what I mean. It is odd that -frtti changes us from "this
>> is not available anywhere, use linkonce_odr" to "it is available
>> elsewhere, use an external declaration".
>
> Yes, I agree, it's weird (although the transition is in the other
> direction, really, since there's no such flag as -frtti, just -fno-rtti).
> -fexceptions -fno-rtti is a weird combination to begin with though.
I got curious and decided to reduce it. What I got was:
class foo {
virtual void bar();
};
struct zed : public foo {};
int f() { throw zed(); }
Without -fno-rtti _ZTI3foo is external. With -fno-rtti it is
linkonce_odr. It looks like -fno-rtti disables some key function logic
in both gcc and clang.
Cheers,
Rafael
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
RE: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.
> -Original Message- > From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of > Duncan P. N. Exon Smith via cfe-commits > Sent: Monday, January 11, 2016 4:21 PM > To: Rafael Espíndola > Cc: Marshall Clow; CFE Commits > Subject: Re: [libcxx] r196411 - Give all members of exception types > default visibility. Lack of this is causing some illegal code relocations > rare and hard to reproduce cases. > > > > On 2016-Jan-11, at 15:57, Rafael Espíndola > wrote: > > > >> I'm not sure about GCC. Note that there is no linkage for -frtti, > >> since the type info is deferred to the TU with the vtable. > > > > Yes, that is what I mean. It is odd that -frtti changes us from "this > > is not available anywhere, use linkonce_odr" to "it is available > > elsewhere, use an external declaration". > > Yes, I agree, it's weird (although the transition is in the other > direction, really, since there's no such flag as -frtti, just -fno-rtti). Drive-by comment: Actually there is -frtti, it's just not defined next to -fno-rtti in Options.td for some reason. > -fexceptions -fno-rtti is a weird combination to begin with though. Yup. So weird that PS4 goes to the trouble of forbidding it... that doesn't help here, unfortunately. --paulr > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.
> On 2016-Jan-11, at 15:57, Rafael Espíndola wrote: > >> I'm not sure about GCC. Note that there is no linkage for -frtti, >> since the type info is deferred to the TU with the vtable. > > Yes, that is what I mean. It is odd that -frtti changes us from "this > is not available anywhere, use linkonce_odr" to "it is available > elsewhere, use an external declaration". Yes, I agree, it's weird (although the transition is in the other direction, really, since there's no such flag as -frtti, just -fno-rtti). -fexceptions -fno-rtti is a weird combination to begin with though. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.
> I'm not sure about GCC. Note that there is no linkage for -frtti, > since the type info is deferred to the TU with the vtable. Yes, that is what I mean. It is odd that -frtti changes us from "this is not available anywhere, use linkonce_odr" to "it is available elsewhere, use an external declaration". Cheers, Rafael ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.
> On 2016-Jan-11, at 15:40, Rafael Espíndola wrote: > > On 8 January 2016 at 19:50, Duncan P. N. Exon Smith via cfe-commits > wrote: >> [re-send to lists.llvm.org] >> [necromancy] >> >> This is causing some strangeness for users of libc++ headers that >> ship dylibs and build with -fno-rtti and -fvisibility=hidden. >> >> Strangely, -fno-rtti does *not* imply -fno-exceptions; the type info >> needed for exceptions is generated on-the-fly. This means that each >> translation unit generates a linkonce_odr copy of the std::exception >> type info -- weird, but kind of reasonable? > > Will gcc produce a copy too? It seems really strange to produce > different linkages for -frtti and -fno-rtti -fexcptions. I'm not sure about GCC. Note that there is no linkage for -frtti, since the type info is deferred to the TU with the vtable. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.
On 8 January 2016 at 19:50, Duncan P. N. Exon Smith via cfe-commits wrote: > [re-send to lists.llvm.org] > [necromancy] > > This is causing some strangeness for users of libc++ headers that > ship dylibs and build with -fno-rtti and -fvisibility=hidden. > > Strangely, -fno-rtti does *not* imply -fno-exceptions; the type info > needed for exceptions is generated on-the-fly. This means that each > translation unit generates a linkonce_odr copy of the std::exception > type info -- weird, but kind of reasonable? Will gcc produce a copy too? It seems really strange to produce different linkages for -frtti and -fno-rtti -fexcptions. Cheers, Rafael ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.
On Jan 8, 2016, at 7:50 PM, Duncan P. N. Exon Smith
wrote:
>
> [re-send to lists.llvm.org]
> [necromancy]
>
> This is causing some strangeness for users of libc++ headers that
> ship dylibs and build with -fno-rtti and -fvisibility=hidden.
>
> Strangely, -fno-rtti does *not* imply -fno-exceptions; the type info
> needed for exceptions is generated on-the-fly. This means that each
> translation unit generates a linkonce_odr copy of the std::exception
> type info -- weird, but kind of reasonable?
>
> Because of this commit, the (non-canonical) type info from these
> other dylibs is getting exported, even though they compile with
> -fvisibility=hidden. On Darwin, this means that a link line like
> this:
> --
> $ ld -o a.out a.o -library-without-rtti -lc++
> --
> will find the type info in libibrary-without-rtti.dylib instead of
> libc++.1.dylib. That doesn't seem reasonable.
>
> The request I've had from such dylib owners is to effectively revert
> this commit, so that their copy of std::exception type info isn't
> exported when they use -fvisibility=hidden. However, then their
> copy of the type info won't get coalesced with libc++.1.dylib's.
>
> Does anyone have an opinion on this? Should we care about the
> visibility of std::exception type info when -fno-rtti? (Note that
> when RTTI is on, clang correctly does not generate the type info
> for std::exception and friends.)
>
> Howard, any chance you remember more about the problems this fixed?
Sorry, nope.
I have no opinion on this. The only thing I would have to say in this area is
that if Nick says it, you can take it to the bank.
Howard
>
>> On 2013-Dec-04, at 13:03, Howard Hinnant wrote:
>>
>> Author: hhinnant
>> Date: Wed Dec 4 15:03:23 2013
>> New Revision: 196411
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=196411&view=rev
>> Log:
>> Give all members of exception types default visibility. Lack of this is
>> causing some illegal code relocations rare and hard to reproduce cases.
>>
>> Modified:
>> libcxx/trunk/include/__config
>>
>> Modified: libcxx/trunk/include/__config
>> URL:
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=196411&r1=196410&r2=196411&view=diff
>> ==
>> --- libcxx/trunk/include/__config (original)
>> +++ libcxx/trunk/include/__config Wed Dec 4 15:03:23 2013
>> @@ -194,7 +194,7 @@
>> #endif
>>
>> #ifndef _LIBCPP_EXCEPTION_ABI
>> -#define _LIBCPP_EXCEPTION_ABI _LIBCPP_TYPE_VIS
>> +#define _LIBCPP_EXCEPTION_ABI __attribute__ ((__visibility__("default")))
>> #endif
>>
>> #ifndef _LIBCPP_ALWAYS_INLINE
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-comm...@cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [libcxx] r196411 - Give all members of exception types default visibility. Lack of this is causing some illegal code relocations rare and hard to reproduce cases.
[re-send to lists.llvm.org]
[necromancy]
This is causing some strangeness for users of libc++ headers that
ship dylibs and build with -fno-rtti and -fvisibility=hidden.
Strangely, -fno-rtti does *not* imply -fno-exceptions; the type info
needed for exceptions is generated on-the-fly. This means that each
translation unit generates a linkonce_odr copy of the std::exception
type info -- weird, but kind of reasonable?
Because of this commit, the (non-canonical) type info from these
other dylibs is getting exported, even though they compile with
-fvisibility=hidden. On Darwin, this means that a link line like
this:
--
$ ld -o a.out a.o -library-without-rtti -lc++
--
will find the type info in libibrary-without-rtti.dylib instead of
libc++.1.dylib. That doesn't seem reasonable.
The request I've had from such dylib owners is to effectively revert
this commit, so that their copy of std::exception type info isn't
exported when they use -fvisibility=hidden. However, then their
copy of the type info won't get coalesced with libc++.1.dylib's.
Does anyone have an opinion on this? Should we care about the
visibility of std::exception type info when -fno-rtti? (Note that
when RTTI is on, clang correctly does not generate the type info
for std::exception and friends.)
Howard, any chance you remember more about the problems this fixed?
> On 2013-Dec-04, at 13:03, Howard Hinnant wrote:
>
> Author: hhinnant
> Date: Wed Dec 4 15:03:23 2013
> New Revision: 196411
>
> URL: http://llvm.org/viewvc/llvm-project?rev=196411&view=rev
> Log:
> Give all members of exception types default visibility. Lack of this is
> causing some illegal code relocations rare and hard to reproduce cases.
>
> Modified:
> libcxx/trunk/include/__config
>
> Modified: libcxx/trunk/include/__config
> URL:
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/__config?rev=196411&r1=196410&r2=196411&view=diff
> ==
> --- libcxx/trunk/include/__config (original)
> +++ libcxx/trunk/include/__config Wed Dec 4 15:03:23 2013
> @@ -194,7 +194,7 @@
> #endif
>
> #ifndef _LIBCPP_EXCEPTION_ABI
> -#define _LIBCPP_EXCEPTION_ABI _LIBCPP_TYPE_VIS
> +#define _LIBCPP_EXCEPTION_ABI __attribute__ ((__visibility__("default")))
> #endif
>
> #ifndef _LIBCPP_ALWAYS_INLINE
>
>
> ___
> cfe-commits mailing list
> cfe-comm...@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
