Skip site navigation (1)Skip section navigation (2) 
Date:      Mon, 25 Apr 2022 13:01:48 +0000
From:      jbo@insane.engineer
To:        FreeBSD Hackers <freebsd-hackers@freebsd.org>
Cc:        Mark Millard <marklmi@yahoo.com>, joerg@bec.de
Subject:   Re: llvm & RTTI over shared libraries
Message-ID:  <ovVAJ_I0kr_8S6cVa0jixF9EZsG5XKsEGllRx66SMNQMIQUVbO2eSxOpAH9VeYeJVWygWAb3wAivQGNfGMs66nVHwliCC-fUS5W_IlJ-VJs=@insane.engineer>
In-Reply-To: <3141FACD-5154-40CC-91CC-0A6C55B7220B@yahoo.com>
References:  <E22DA198-862B-4B99-8E0B-E63AEBDCCF35@yahoo.com> <3141FACD-5154-40CC-91CC-0A6C55B7220B@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]
Hello guys,

Thank you for your replies.

I've created a small minimal test case which reproduces the problem (attached).
The key points here are:
  - CMake based project consisting of:
    - The header-only interface for the plugin and the types (test-interface).
    - The main executable that loads the plugin (test-core).
    - A plugin implementation (plugin-one).
  - Compiles out-of-the-box on FreeBSD 13/stable with both lang/gcc11 and devel/llvm14.
  - It uses the exact mechanism I use to load the plugins in my actual application.

stdout output when compiling with lang/gcc11:

  t is type_int
  t is type_string
  done.


stdout output when compiling with lang/llvm14:

  could not cast t
  could not cast t
  done.


Unfortunately, I could not yet figure out which compiler/linker flags llvm requires to implement the same behavior as GCC does. I understand that eventually I'd be better of rewriting the necessary parts to eliminate that problem but this is not a quick job.

Could somebody lend me a hand in figuring out which compiler/linker flags are necessary to get this to work with llvm?


Best regards,
~ Joel



------- Original Message -------
On Saturday, April 23rd, 2022 at 22:42, Mark Millard <marklmi@yahoo.com> wrote:


>
>
>
> 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
[-- Attachment #2 --]
PK
Tclang_test_dist/UT	_b_buxPKओT|+clang_test_dist/CMakeLists.txtUT	_b_buxm Fw#,	L@ڠ*?o/.pg~!xKh_gdw<=#{O4M
Xp99LjKAȑO\`P#lrvlJLjbB](sVW2#_PK
ओTclang_test_dist/plugins/UT	_b_buxPK
ओTf&clang_test_dist/plugins/CMakeLists.txtUT	_b_buxadd_subdirectory(plugin_one)
PK
ओT#clang_test_dist/plugins/plugin_one/UT	_b_buxPKओTy4i-clang_test_dist/plugins/plugin_one/plugin.cppUT	_b_buxRn0}WxE=xUH\%Q!}BrmVU%q{&$B1QVfq`l2zꑿ-{
.pdi\f{K߰,+xf)y,-	JuxM7G:gi]qG
2~$O>D]7v 6(^yAOC
Ie4R.zЛSn`Xq!Dlڲjx_Trk'=ˉPf/Eeoӕݡ-X*-
ڽO 	ˊeapA}Qݕ7%Q#!DPKओTmwz1clang_test_dist/plugins/plugin_one/CMakeLists.txtUT	_b_bux+N-qrw
Q()MKJLIL*J,P(Upru*I,JO-O-IOKM,)-J-Rz0/ 31䊊⒔x#.AE釸R/PK
ओTclang_test_dist/core/UT	_b_buxPKओT%Zclang_test_dist/core/main.cppUT	_b_buxn <q{lׇZJYkTUw/l$aW3?g~D(	;\^?X3c8jlccРT*Tә7S_E0#L5xj:q֕ \b҆4|Ϋ(7we02FzE)p3av7n^>ю_h+O$0
|^ƒְaɉ(_Q6D*vI-Ҿ|rT1q^H&3.D
yΦN
cnVڞ;h
eoQ7
SvcQ=`K<@j
8fO.	gZ=r11 XE䞺F+j;oK<7H}>o"l+~|xvzG`J}KSjNרBA=mzֻ̯깹jx}{q{{w<ɁPKओTd]b" clang_test_dist/core/dlclass.hppUT	_b_buxVM6Wnnfz^_ 0hilD;DrR䛯7C%ۗDa+79ӮNJc
VK,<+JˢگBӜj~h1E0c L)(evYcU7ZN~e'EIPu`sV2y|IVšv.N5~nQu5grv*r/99fˋ,R{?+iOWLyqcp)73-X95>3`_zr?k'KkrJ=	ʑۢ:X%KᏅ
5twz9OjL<Dԍ<B>	VcXEg' 0 vN!kX=rz{((&0oJ4Oywhf/IDw;Y9dS-hQolXܦV<^0OX)ؠڤ<boLN;s̓FK]_VDׯ,HSxoMٱF,CTt:P<hd	w,87j8ʗݾ_	.=gY$n?}i
ZS߻m
\11SɭN}&:.@eq$7ׁQy®z!XD<;T!gaQ98XO3u((ӵ׬Off<z'g`ePN΍p]8gz@?^7o/LۮTv+|]n˜흘=V|PJAQXjPQuwFZēJȯ:q_+v㴞drܥ4&6Ɠ{rO_
e\jI
]^&鲽qV2tSMDŽ@R82p3MFihQ#ﵕ~ 7!f$5朴ōlƷex-'%^<>o-^E
|tܜ/j׈PKओT8_S#clang_test_dist/core/CMakeLists.txtUT	_b_bux
0}
;A{2v"FWVҦ eB$)taǂ	)9D1?<?W	?"qSǐ,f\k{]K<@l=28	R!TD#+C_/$:4
:GeJk0%PK
ओTclang_test_dist/interface/UT	_b_buxPKओT.M. #clang_test_dist/interface/types.hppUT	_b_bux
0E/tꯌfuM۷U!\'	pˆ$Z?<iFc_60Y3pwĵQ29\wt+);i+rn9o!c?TIR[PKओT){(clang_test_dist/interface/CMakeLists.txtUT	_b_bux+N-qrw
Q(I-.+I-JKLNJLIL*J,PUq
rstvU

quQpwr(I,JO-//-JN-RN0<PIeAj1XDPKओT=$clang_test_dist/interface/plugin.hppUT	_b_buxm
0}@6ynʈm:[[T24/>`?"8+IX9$ES<޼}uFG%LAJ<C~H㝗XT22u\VEYMdp#&p묬Uu֥t6r:0<f{#]|PK
TAclang_test_dist/UT_buxPKओT|+Jclang_test_dist/CMakeLists.txtUT_buxPK
ओTA'clang_test_dist/plugins/UT_buxPK
ओTf&yclang_test_dist/plugins/CMakeLists.txtUT_buxPK
ओT#Aclang_test_dist/plugins/plugin_one/UT_buxPKओTy4i-Sclang_test_dist/plugins/plugin_one/plugin.cppUT_buxPKओTmwz1#clang_test_dist/plugins/plugin_one/CMakeLists.txtUT_buxPK
ओTAclang_test_dist/core/UT_buxPKओT%ZWclang_test_dist/core/main.cppUT_buxPKओTd]b" clang_test_dist/core/dlclass.hppUT_buxPKओT8_S#clang_test_dist/core/CMakeLists.txtUT_buxPK
ओTA
clang_test_dist/interface/UT_buxPKओT.M. #e
clang_test_dist/interface/types.hppUT_buxPKओT){(Jclang_test_dist/interface/CMakeLists.txtUT_buxPKओT=$'clang_test_dist/interface/plugin.hppUT_buxPKD

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ovVAJ_I0kr_8S6cVa0jixF9EZsG5XKsEGllRx66SMNQMIQUVbO2eSxOpAH9VeYeJVWygWAb3wAivQGNfGMs66nVHwliCC-fUS5W_IlJ-VJs=>