From nobody Sat Apr 23 22:33:13 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 0C7CE1A84717 for ; Sat, 23 Apr 2022 22:33:25 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-25.consmr.mail.gq1.yahoo.com (sonic303-25.consmr.mail.gq1.yahoo.com [98.137.64.206]) (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 4Km5dv2d6Zz3Fb8 for ; Sat, 23 Apr 2022 22:33:23 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650753196; bh=abHDq5HRcjuc0Q6GsW5iQueA7x9lJTRmYcNxUEO77o0=; h=From:Subject:Date:Cc:To:References:From:Subject:Reply-To; b=a9+4V6n8CGgS1ogdbkMRanGTBeZLNpyoPdjai1QKZfkXT6q4sdYX9YidD88h42jG+wkN+1zU8HdnMpHZI9Oum5udAM0e2qUNm1+9Vgw3RSwd2gLVy/KBKScX7/DNPD93tjr27VrvJEsFqvQh0wHzudtC4ikFjSSmHmndU8W7MX7HeQyzxiTpunimaSLJud75m5xLXHY8YMh7AVgtCLPchtivyCc/e7Hq8LxBaUPMd1jcpX/c3nU6P/9fv8L7j9o9wQNGrKN7kfphe+mI/nGZXqeGlRf8e9n7+lvmNZ4U0A+BASZfAhd8SnVlL24xnSUdsiWbrF1CuA/oVYHRVQb+1A== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1650753196; bh=nrRQFYVZcyl5xY7c031lO3Xf+9NFh2fGEWBaKuqOPAo=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=NCnIrum2b+lDqZ8GKe+QjZ/+bLEV3QAIS0J5Qv5U6V0kI8JKa7X//V4CVoAJ5gQ0vnx2Crl/foD0rYJEte9EyW9HfqYBZhpxMv3aJq6baZhBsPGjeyGFPFt177Mx4jGEMFeBJIVZu7Y+QCl27rUqa2lQmcfcScnMvQ0+K0WOv4MqjrpatOZgEmXMpoPlvj0o0c5jYI/z2lzIPf2RX3hMd5O8/8XVxNsK7v+L3iyFlrlWsKzbhA/lFKAJWZDChyfd5D8i1NITXdugJAyZkt6JyPc3rVGhVhC6WlxbVbevs7VVopQBX576IAbnOfMoN2tvdQiEGYqHTL4rsh76CC02lA== X-YMail-OSG: hsaud_oVM1nXKvZY5zD3TvTPopB.9QxYPADhVWhSAP97j3mMajtPYWKa_9GHd4Y 61FSF4_MV1kLE7mRpuy3JnXKi6gFtjpC1mkCHJI.IyzwUTAJOWbId0mXIjGDxz89pyMxxLAcY9Fi Q2G99apJL59qEPEQy4HYJjAsqodYpfDXoLPuFVaOUjjaD86OtPXrqYBnm7VbG6SddZY4yMyiwLEa z2U.6LlW932wclznDjhGKK9yfCX_Fph6KpM9K0Rt8_WTXcCT8Jy6ujXM6K6AZ_0Yl8qL.HYvfDvV Em8vdgIqeUAhBbu3tmnrwREAC4UsbHlfLiJ3TX.8m6UtlUch5Vpgm2VVusUHVxJqLezoJkLmNxsF nS92t9vHLW1XWcpj8cWzkqGONALHAHsqbvsgVXJaUCIOSVvE.RheQLKfANCDb.MGmBmg2snoQkaF TZcMVKVFH0Oj_dw6wUQ8qdMeZmMb8.TXVgPy1tQpLtCG_m0nBt2l0_dDC6QkU3Rh5VmbUzYWYoOf eVcxMkIUCNxL7pZ_wpFlCD.UDFJvToijdgtOnJqNx64Rjft.komRu6xRuEciqGVNS7u7UQUs0ALb d1JruMKB753gKL9vHHHRAoI5JJyMwPVr9MVZT8QZzni74SJZIUe7kDDTbakNgzwT8ckrsslH8Ut5 LXKGqgRbKuKWpNFXf9REkApdKHQXIIS8uJ0.r...GWcOhLQZDAgi34CFPFi4bNIOU34L9a4AhL61 EUsmslMSN1FvMEtYTqnGcTB5Bdr.mUg.g7D0nOR2xLabPWD3KjxzuLhk8c0fAsEwV9YSllY4_YZJ ERnqDaqBWc6trC7LFvZvhA1WJA94N5csveTsXhURVkbv.sP41or9jJEOkpArnwF9.WjoiHCuVL1T tTb_zAYDKguPhyzVb5rDxnq_jeh4zmEFSFs_E6mKYAZqC4X4tUuFrmsxAjyzVGRTXstNXDrHY4XQ GOdPfQqeSMhh_JR4SXpeOANe_jr9zAEysA1PN_T1Yj2.JjNUlVmIbPQgcI2LH0bhr6aoRXIT3oTs mnHpCJ4xSZYHy1A.ic9H9JCDcRhrV94rqCMZFygvtSGr7iSWfepqo5ew8u9eTQ4CyfatbC2HnADf YxasQXku9dna_SuTrU.JecgS8dKsvC85xS.CX_yBcItpWFaKbi_TddHt6P8P9vCXllwNDKA7jtoR LFU6s2bdz3XjeeK8PWjsOnFe3F1KHx7xQsOBOFtxwBRJozXjjgjpjC1ddCaMXSbu_VdAlTht74.h Bwkb5xecbaRCx2PaPfFawgsw8DTSDe24MK.mAwm1vo1Wn6ke0DLor96Kg4L4wDeMjXP1zU1a1aZ4 X.q9vOVlN5gfP8ew8Qp8nNxqpkQC8BrXblZ0h3eEuJU__oFhbZkHpPuewvtw4WWUtYZe9KaJhhuP RX4_q9yL0oKOjj_qc3KIk0HBRr_0xZZH4QCw0uAEuH0AVTvPNeeRPK1_v4t8jOGGi9x0NB_1YAyv _OZQ4wIXGeWuyf1bB4SuTBQhSzuhvWW_QjgDDIP5Ht3Ri_LabSuVJJYI4ThvEAuCR26KXYDt3NxU .X9cI_OIsIusqaWPIb0XJT.djFVcZsIgF2qPowspkc0FZYUtWcty5IicLrH.1yrNf72Xz6tR3Miz f9JeKJI4qcjuLUdO80W0aidtVsapsydp3ekVdheijizjWhW4zoi3V5ls7jAbTB2srSI7.uzZypVu xIGPWS0P2DfxL.sPl8MCJ3HAgIL.t9Pb7gE3CtKY0tyoNFtd8bd0ykMoluuuCM1K9J1mUeTugJM9 tjhYgC2833E6GQ3SfIrV6lHeWgWDhhhDladbsPR_66YDXu8zYlv3TMG3NHToJTFQH165QPtTd041 w7zTc8A1xaGykZmZz33.ziiaYxU4hhyLs6I1FVoUbxq.GLpeKiEX9jISRmhcOXpWMYZuAfhsC5Qi .8IZZOC5bFr42UoIRVHs858olT5WHhN1JLgJpSkc9xxN5gEbvO1xVCbS03hR_IEatCKvPyp3ZgxM b4vDvRTHM5nSVlAq387whVfEZAiBk0u2qR4pa5wAUflN58XP3.6a2w2r0c4FZy6F1Kq5jZ4GhXzX uV359rBBXTcWpuHDt72gTnkIfgV8QJMVDkiU.Eolfz.XPgRy101FpptOhFYP8Xtkh63Ch2yot25N 8Og1XyC3ot6LasfJ88okDwRU5JESltuKDCkGKzCb6kCPJF9DCAMAByfJtdwJ.3UrMzNVgI_RspYY S_4XLM7I6RZNDCgKnbOpr.wRvIqsJB3ng5rkPbSJUX_VYBwV.pOKDhhK2A5avOB_wR.zbL9czaHD nhWNmeeE7VpsJ.alibsTu1MI- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Apr 2022 22:33:16 +0000 Received: by hermes--canary-production-ne1-6855c48695-pbbz7 (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 9494d0d5c406adc99c8bd6eb8f4f752d; Sat, 23 Apr 2022 22:33:15 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 Message-Id: Date: Sat, 23 Apr 2022 15:33:13 -0700 Cc: jbo@insane.engineer To: joerg@bec.de, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4Km5dv2d6Zz3Fb8 X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=a9+4V6n8; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.64.206 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.946]; 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.64.206:from]; NEURAL_HAM_SHORT(-0.99)[-0.990]; 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 =E2=80=A2 Joerg Sonnenberger 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 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 . 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