Re: llvm & RTTI over shared libraries

On 2022-Apr-23, at 15:33, Mark Millard <marklmi@yahoo.com> wrote:

> 	• Joerg Sonnenberger <joerg_at_bec.de> wrote on
> 	• Date: Sat, 23 Apr 2022 21:33:04 UTC :
> 
>> Am Tue, Apr 19, 2022 at 11:03:33PM -0700 schrieb Mark Millard:
>>> Joerg Sonnenberger <joerg_at_bec.de> wrote on
>>> Tue, 19 Apr 2022 21:49:44 UTC :
>>> 
>>>> Am Thu, Apr 14, 2022 at 04:36:24PM +0000 schrieb jbo@insane.engineer:
>>>>>> After some research I seem to understand that the way that RTTI is handled over shared library boundaries is different between GCC and LLVM.
>>>>> 
>>>> I think you are running into the old problem that GCC thinks comparing
>>>> types by name makes sense where as everyone else compares types by type
>>>> pointer identity.
>>> 
>>> Seems out of date for the GCC information . . .
>>> 
>>> https://gcc.gnu.org/faq.html#dso reports:
>>> 
>>> QUOTE
>>> The new C++ ABI in the GCC 3.0 series uses address comparisons, rather than string compares, to determine type equality.
>>> END QUOTE
>> 
>> Compare that with the implementation in <typeinfo>.
> 
> Looking at /usr/local/lib/gcc11/include/c++/typeinfo I see:
> configurable, in part based on the intent for possible
> handling RTLD_LOCAL (when weak symbol are available). I'll
> quote the comments for reference . . .
> 
> // Determine whether typeinfo names for the same type are merged (in which
> // case comparison can just compare pointers) or not (in which case strings
> // must be compared), and whether comparison is to be implemented inline or
> // not.  We used to do inline pointer comparison by default if weak symbols
> // are available, but even with weak symbols sometimes names are not merged
> // when objects are loaded with RTLD_LOCAL, so now we always use strcmp by
> // default.  For ABI compatibility, we do the strcmp inline if weak symbols
> // are available, and out-of-line if not.  Out-of-line pointer comparison
> // is used where the object files are to be portable to multiple systems,
> // some of which may not be able to use pointer comparison, but the
> // particular system for which libstdc++ is being built can use pointer
> // comparison; in particular for most ARM EABI systems, where the ABI
> // specifies out-of-line comparison.  The compiler's target configuration
> // can override the defaults by defining __GXX_TYPEINFO_EQUALITY_INLINE to
> // 1 or 0 to indicate whether or not comparison is inline, and
> // __GXX_MERGED_TYPEINFO_NAMES to 1 or 0 to indicate whether or not pointer
> // comparison can be used.
> 
> So, to some extent, the details are choices in the likes of lang/gcc11
> instead of an always-the-same rule for handling. Below gives some
> more idea of what __GXX_TYPEINFO_EQUALITY_INLINE and
> __GXX_MERGED_TYPEINFO_NAMES do for configuration. Is there a combination
> that matches FreeBSD's system clang++ related behavior? If yes, should
> the likes of lang/gcc11 be using that combination?

I should have quoted a little bit more that describes the
defaults used:

#ifndef __GXX_MERGED_TYPEINFO_NAMES
// By default, typeinfo names are not merged.
#define __GXX_MERGED_TYPEINFO_NAMES 0
#endif

// By default follow the old inline rules to avoid ABI changes.
#ifndef __GXX_TYPEINFO_EQUALITY_INLINE
  #if !__GXX_WEAK__
    #define __GXX_TYPEINFO_EQUALITY_INLINE 0
  #else
    #define __GXX_TYPEINFO_EQUALITY_INLINE 1
  #endif
#endif

. . .
> #if !__GXX_TYPEINFO_EQUALITY_INLINE
>    // In old abi, or when weak symbols are not supported, there can
>    // be multiple instances of a type_info object for one
>    // type. Uniqueness must use the _name value, not object address.
> . . .
> #else
>  #if !__GXX_MERGED_TYPEINFO_NAMES
> . . .
>    // Even with the new abi, on systems that support dlopen
>    // we can run into cases where type_info names aren't merged,
>    // so we still need to do string comparison.
> . . .
>  #else
>    // On some targets we can rely on type_info's NTBS being unique,
>    // and therefore address comparisons are sufficient.
> . . .
>  #endif
> #endif
> 
> 


===
Mark Millard
marklmi at yahoo.com