Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 23 Apr 2022 15:33:13 -0700
From:      Mark Millard <marklmi@yahoo.com>
To:        joerg@bec.de, FreeBSD Hackers <freebsd-hackers@freebsd.org>
Cc:        jbo@insane.engineer
Subject:   Re: llvm & RTTI over shared libraries
Message-ID:  <E22DA198-862B-4B99-8E0B-E63AEBDCCF35@yahoo.com>
References:  <E22DA198-862B-4B99-8E0B-E63AEBDCCF35.ref@yahoo.com>

next in thread | previous in thread | raw e-mail | index | archive | help
	=E2=80=A2 Joerg Sonnenberger <joerg_at_bec.de> wrote on
	=E2=80=A2 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 :
> >=20
> > > 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.
> > >>=20
> > > 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.
> >=20
> > Seems out of date for the GCC information . . .
> >=20
> >  https://gcc.gnu.org/faq.html#dso reports:
> >=20
> > QUOTE
> > The new C++ ABI in the GCC 3.0 series uses address comparisons, =
rather than string compares, to determine type equality.
> > END QUOTE
>=20
> 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?


#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


=3D=3D=3D
Mark Millard
marklmi at yahoo.com




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E22DA198-862B-4B99-8E0B-E63AEBDCCF35>