Re: llvm & RTTI over shared libraries
- Reply: jbo_a_insane.engineer: "Re: llvm & RTTI over shared libraries"
- In reply to: Mark Millard : "Re: llvm & RTTI over shared libraries"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 23 Apr 2022 22:42:02 UTC
On 2022-Apr-23, at 15:33, Mark Millard <firstname.lastname@example.org> 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 email@example.com: >>>>>> 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