From nobody Sat Apr 23 22:42:02 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8BF261A86A2F for ; Sat, 23 Apr 2022 22:42:17 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-21.consmr.mail.gq1.yahoo.com (sonic309-21.consmr.mail.gq1.yahoo.com [98.137.65.147]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Km5r84MdNz3HPd for ; Sat, 23 Apr 2022 22:42:16 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650753729; bh=Hl9r3pKAwlpUzhZ83Q+F4Rnu66hWxz2FQygpClWivqk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=J1imidnJ+uJM/UOcLWC3gLFuGKD8zPII1o6Mu4FLtkXuPSw9Ny7kt+s+K8gFQnZLLIaRtEdwTLiG322xp6mRJfSWNsmjhk789Kek/9GxhlFH7Dh6r4EmLaQQUQKu+2Oagbjchn18x8t8exYuzNhVhp+PdhTvfkdOjhMoVW8yJ3/o5Wn8AsnXouTmO6JyzvF3LN9bu+wg5zpD/4iws/6ijoN8D10PQhKSCWJFdmiycA3qEIBsLDfZZ5XPO6/1A6U7LS84BGCrzMRfs7Pt476zojH6maG4pBnabMtTOkxMy/gIeWjjdHwXXEJNnjONzLDnM8wJ3iyWLyFixj3A3y2Jyw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650753729; bh=G/oAj0JtbNmbybRGNikJI9c4C497ToCuskCeBioJGIp=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=V+wz3XDBJBduIXeSdZQs48Rgcz/66z7SsW3LFLNcGDDNwAkL6j/Gp4CGABI/PhSMqKDxvhtP++COVC7aYLifqJPTjW0p1EEnond5vwB3nafsJJ+MFDDhUANf9ggodGu+ZLs/AGEYCgsfVNqgA4kqlZIXQalpu1pZGjvVFOcEpFYb46tUBnr1mUQtz1DkjrM0LVGfV+VlWOfEUhMYHNIF7wGVLMyP4UZk2B2uoRVNx0c12HBAe6azWJgwWRvV7ltgXpoAtofflhWCjlxp6G2dAaMmvAdanEE93wz6y88aQ21/mwTzqseX6g1m/lD+HmflC10Nc9UEadvHV6sm5StOQQ== X-YMail-OSG: NJRfDs4VM1l2HBW0j3OLKj9WicL1U_s0Hx3sI69NU1HUrz.qtCvI1iqvKpAAoBQ b1RSiqv88SwPyxieMGg3xTEOyTKLagqkdMlWuMA3RMqQU.zFodKjsW97wwCsNi4UBP.4Wma.6J.8 FSLhJizu0Th6GKYqt2B1r7HnIB3kn9Us5ZzEMIAjpI3p7Swxa4J_ebdC7j.MlE00pmKuY1uff1Ub p28Us6XGZvqbzai6b3ygdX4hTSWQgJV0yQSI81mGYZMvQs98G47uH3XM.ODR9W_dcrEFIBFzIdIP alGDY4rL8A7z9Lp9P9INK9UF_AGm6LVfx50INxaen4O.tMvcl1icn33f_naPz4zmRYXANHnsQZoK T9BDb.39IpX_YWnJsmy05kKcV.TWJ3iw5FOI8c7PtCem.KJ8S6l7WYzGdaF05Z6XLTfWYbqJSrtX 4ScP_cHgQiv25J0xbS3u3kbcRh2qcD2F78.Rm8NDnUnl3.PVVHrp6Vb9_6RUuWS7PTlIQqnQ47qh JCewFnMqJC8T7XRJr7A.Es3cvGFvEELRS_JJbjCL.ToGprH6vZvZ5SqIwiBDVEZKZG7oqM2I0_Ed zYdYV4qWVQZsetB6Vhc0zOLZunlzyeRw1wMSmu6M1jd.QtYQC_BYWIVfsZQm6WDiKO2hSI94HytQ L_OPYm2j9mG55rpI_MbIZY5bL1awp6lhLy6iRmpOqu4esl_vx7ipo5nowZILjcouzqavsu2VvTaF 9hIOwgM5U.3chPjPb0eaVXPvWvkCxa656ywk6iNhqexODwITwE4t29TRH6DjxwkQJCbmNlhfM9zO Fs.VoGnMnYtA.ql.6Qyi9kfl7ISReDHOfd8lExXKuuywt11ypwBdu1vVzshyGGyPT2BieTSnoHXO K0_OcdUXcgd03dYyEkVNMSTQmbUoAIoSs2zKYOhR0nXFbmR78gsN8tHvBzECqNSGC.zUi9KZiFwE CFMjHn9Op8VzA9J988MnZwB0457pSue194HC12zQIvqA8mIjSmj_cCekK1lj4hxETPvkfHUe1zHD qo3A1ISmSm13.pIf4jUJGiuPKt.Dx3cZJqhkX0fG4lb4FuNeYsY1RBb7W2ll82TKPO4r1d_xDr8F rO.OFtVWYx9fRlYUO4DlxWn3NhNMgd5ICwdVPsCQOhy2.uD8yNd.W2PhkOSluAjf0VMHgSwV7cmh 5SyHOSdHM9C2L4CHIz2ObCCcOOjehetf_7_jQf5LlUOp2baFNGT2VThrJ_4UOds7BoYwKj7hYsMc ITGaw7aqts0qYNlXiiCnKdrOK8xqsmmn997UD72f33vHaGjhsJFYuGFpnICJqgtl3ujmx1OYYuHs QcwxoH6Z9U2qWnpqX2X3_xuw1NW7gj_74BFMMiU3PCQCYfJ0Z6ePFLp5VKixZFs58ux4109TntUX HBzXRVAQeTtyYn3Q5f9sxvfa9yDberUTR7lazWS5W11pMD2AA_kzz0lbnomz4lBJ5kmgh93tRG9h MSzELOUsFPPiDqKhDgftuLQxTBx27VJ_mIjxZTFXBdAAzhZUcjuFu_qoeoETjoCzMaZr4IFyYfts W45EJf8AA5jDU0m8MNnFQTtoNYhEsLGQM12qJSZPdcyJS8JvZXnGL22fdyN4WAyQGqd.E7qBJyRN UUqiqCaGXdv_Two_DInCGCyhsnTfe1AZCcvRmhPx3R_GmCvqldg0OB70.NR8X1k1TKhz1BMkNSB8 dXLUNSEvxWjC7IC4ErwqEQ0BSr9Oq2r1Q5NGkptBKnEL4cIkRCCZsWE9dw81p0GfCEtX85neHGyR ROMJj6eCXefECReJBfYVFNWlIIF6yP6lWqrZDu4f35Y9sRmGOyGQCuRWyfm45QX20GuiQQ6IgUOF iDOZsJ_WxoGxmfWnglkPPOOS5GZ0okbqN11ibfpU0tQer4p2UL287dD71gj.SY1J4T53PBonJehF sooObsO5QYnp_Tcj6v4O5WNDsjkSRcjwHGKVB3zLr1gdwHgf8FHlsL7lkLoBpYIDNm9tLGrOlYAX VVeYuYNo9MsMCJDKNvUGQrkIILlNtLtwTlU84uPdMeappN_w2iqTeRO3GB_cgs0hOxkNywUNXTzD zQ0sBwp5mkXMEjk.s5oi_e9BPujhakfklqEeeHdHzhD0ShKozWtVO0yG85O9kK9knEqVC8fZlMSR M3tF_bAfORAJ3nTXvIypVidnePvCz82VpckqxApxt16jFezv1L8K4re4eleHDA5IqsfUBa2VxTND KUEbHT9pc5pjx9Af7zAf1BrcL2xKlhitcHc_VlODOFr47P7ZYmFhX3W9T8wQbVV_V5dQkrd.6cGy 6oKdroiDLdIz.jaIEP2v9 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Apr 2022 22:42:09 +0000 Received: by hermes--canary-production-ne1-6855c48695-qqb7f (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID a5857a41e83f5b6ee9e86e5c01f45cfb; Sat, 23 Apr 2022 22:42:04 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: llvm & RTTI over shared libraries From: Mark Millard In-Reply-To: Date: Sat, 23 Apr 2022 15:42:02 -0700 Cc: jbo@insane.engineer Content-Transfer-Encoding: quoted-printable Message-Id: <3141FACD-5154-40CC-91CC-0A6C55B7220B@yahoo.com> References: To: joerg@bec.de, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Km5r84MdNz3HPd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=J1imidnJ; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.147 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-1.44 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.95)[-0.953]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; RCVD_IN_DNSWL_NONE(0.00)[98.137.65.147:from]; NEURAL_HAM_SHORT(-0.99)[-0.989]; NEURAL_SPAM_LONG(1.00)[0.999]; MLMMJ_DEST(0.00)[freebsd-hackers]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim] X-ThisMailContainsUnwantedMimeParts: N On 2022-Apr-23, at 15:33, Mark Millard wrote: > =E2=80=A2 Joerg Sonnenberger wrote on > =E2=80=A2 Date: Sat, 23 Apr 2022 21:33:04 UTC : >=20 >> Am Tue, Apr 19, 2022 at 11:03:33PM -0700 schrieb Mark Millard: >>> Joerg Sonnenberger 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 . >=20 > 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 . . . >=20 > // 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. >=20 > 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 >=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com