From nobody Wed Apr 27 01:33:15 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 4B3721AAE075 for ; Wed, 27 Apr 2022 01:33:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-21.consmr.mail.gq1.yahoo.com (sonic313-21.consmr.mail.gq1.yahoo.com [98.137.65.84]) (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 4Kp1VM2tfsz3pdh for ; Wed, 27 Apr 2022 01:33:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651023203; bh=RiMCp+nX40/KjAH7Pv1ZZrrEzbx4Zqmx+A9hoL7Lxm0=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=X4j9a+F80N882xmmxgmKr36HOlSyUYJvVHdCJ5in8gMfqFjopNCYCU+4wYlsUgDJsUEfnR3Bdj/9VuQp/Z3B331Lp71s3Y6JfI+7ikCEvnN7A3rO3vm5280rCEre332+IQBn0yrdpeGURC8bYgIzBRp6e0senggWzlF4AY9bG/OJvpKnI+0rQns3Et5Xdu3Ide8Xpy8AqorSr8AV2d6GdJDD/GXAkXmKf74Pg0o6tg8tyqhOWvfR+f+5IvafIBHD6CnBMOWlT/eaxq1D0ghOVKOWNhHPqhI0yOAioq7CAPLJSB1eHc/Rt+1pdKZxrudhoYKtKs7S+CM1o6N8zPmxQg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1651023203; bh=trYh7Z9zKKIF/GcVWhs1R0uRAI82entkiC83jXcwIuj=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=cCWDV24eAY3XD6focj7zYV+5dTRGON29eh5qcMVn0mItFMHJBbD/+0qP48qMYaYC0reUuKdUl3x1mnxqelNKujSgOr7fRznrBvc9wjA74VXVOF8BeHMBeZZpHVOMB0X7tLOBikhZUp4MuVEGf0KOt1Ez1DDcCOEYlgHzOp0tGttl1JYJt4SvmJuTnBjmuPgeQ8ZvkN/tc74FaU2bct3U+2nbR7oDj9Oh0Px2QycJe/9++3wzwdNn7x9Vko7jTc1yyy+JblO0nsMHxZEV8N7vpwUdEwMK0T+J4Ilbj0wkD/fnCdZZHJrBEt/epbk9M+kAhlYUvBGFG3N6ARqS84j2Sw== X-YMail-OSG: H6sTTzsVM1l9mRE2nudEGuO8Ass7fLxUNIPHiX3Cc.Df98.vgW57u6ipu_OoVoH HevksybqfgnBSrYTG2wG_AicMyTsDZWwQyl7xmgyiahBw8PZSqUg18HnE3fXmmzquO0QLMNSyQDD oDH3PR.m4kpeSsQZsWUvRKNtreAcFGIptXyVxEg2_BNgXlrotAgt86Vu3uAgqWqkEZ6v.CFy5sFD x.DGSXkeTvUVXd6POys2JeKZF4.jI49C8UXYRyg5tn4c5FBpBlZm9IEUHGYNFhhl5glPHYjHqzDz S0bs_LMszs3Cqhi3Yt7Ws.MYKIQVMEJgYIfNkTy9mKYJgvy17dVHuD8O7KGs05ruELCdwTjNFlBq lZc8EUq9UGB5fAU.z_jDT1AGypv7qJKrI_HoHAp6R6yicJF12Fg3h1VM.e0Iio5ukpON0gaOSHi_ wWrSxifSljxKnljM4iClwSosKyVmXrcQHUEW9W63cfSgUHOWkqKj0VTY5lCgGLEJTasfSZEpbiAO x.XHtGPeY3uJP69r_190GrMiRtZvOP_BBjAy2DkSZN_fqlPzR7inq89LutomkSa3LtVTbTio0188 5GNIklVLf8RPJ1RgcA34zCN4EiWfXsnmH9y3FXY7UOirrKL2PTKmTPHtUjPy7xw98T6cHDrpALdf XvOjsxzua_WAMsefO9.hm21PvRkEM1K1P6_g_nq_xxjrDt5IucnO_z_KPIK8fMamL0Uh67O4qxL_ hNRz0bJDcoCRYkrRTXEQCCfMpo7bK8Zusr2Dsre2OuhcJL4gzsheT8k.AfGNdGd1dHYgkntc8NfR ly4oHY.ddfoZ457S4Rny_4_wyUwWiyeut8NTmQMm8czQmf3nqPBOER6B5t0iYs92NL0.C1qgGPAk eDptwi.r9OdYSf8dH0frKFfMp3PrAkF7xVGhgKmEomWT8XT5E4tb4muUem8N9aMQsxbPKSIeqHJM 3e6sWpgWyloNRnBF9AIWkRbsI2sByA91AEkhg2EoYR2GdLfdRkeuVcjDehSDv7984TCsqvGYYZCg LPhvY31vV5WRahx_a1VLobKzCV37QKuWpA4sPK62KWcCWqOl9UM20z5yvapV22qVnk2zasVMkzot znM00UZv2eOjJ_MWGe4FFOz78tZa1rHdhX_O4jI.430RlpAckl0nCq_grB3rJeyjw3rR0Z0LO5gx NXyKk9E1335WVa43xCZx4MgpdmP4zSMqz36qfdsklBvsUSLKWJabjOhlhKMy_40KCddfsJB3pVup qUWCWZ4FBWHojgzfXngiZxYi00KvHHr8xI.11uGlaOvtRB49ic0.Qk8bICWpzWX79BatCf2mOjxB izYJ2NRjY5M8yLpxa.jH25T1Cs1yodwLzrRl102YbIha5WlLa1po2bQhbdTur2Pq00vVOaFTNpuT yI8P7mMdpFCRGQhPbS.MWwvKqi8XsieD2AHymtO1MgbChsaoEEKzr5wXO6WXmfEwFkLRP9SpZNwW 05EQW3weXWd2TEXrgJOo7YaNxbc8lanxj4hfqxpKqlS4b3ccfzj1RU09KIU4EQL5UMxEH8GwwE7b qLrwTCky8sJgPAjAgE_lyOw5Uet.0Hj706MvjdgN7HteibcFZfFdU_W.HrbUcK9w_6Q0IrdaKNwd aHHJdA4FljyzF7QrJSErcCh2SvvNXY79d7rjgAO9EJPaQW2U01OATxeKmV4VOiaFxqI0cSrqWru0 9CqOr4deUNu0qp8LkqThWzr1a1bJJAP1MsgvLaWheFO3yZA8EnsmvT6rAryRZPHWYWwhlFlsaeYQ zFtbCW.VK4poNnHpHMk2p1MIvWUdEAfBgCPuy1ffG9aEr2ZTegU4XSU9yzmFisNUOkHgLcgXdgBX Ei.0k59yoQ4mhTGrykaci.uBElBs3t6ZYXTFAA0jZ5jA9mOxxwp_NPgUC.qtJm3Jqy61yhkB1VSq NS_Ubg8tHKU1ZIgPHHAy5UjbpX.HZ2QvVkXa0lfZxbuL1IpyLDMim5ua4uPXXY3zL19KE4XemCDb 7Fd.BSNGoQVy8HtAoy6PkrkAdKeQtIgI6DwXNLLmz5fKXKaywZWLFjZ0QVTaI2XwrtKz9.q14Jjb m_fqHcIpEuIHlkO4mreIxGO_WuO79ujOG6URWa3lDklsO1CPGq7QKwzwd7UhIpEy_rqGzq0LOyXt SlPqnFahrIhRon3GBa8MNxKCWauBh6XJ5muCXquB5nlgBg7nZ_NjtDnLq_AUFmXL71v1CblxsT7r dbWuD0qtBXxxnS4p.0BCrjj_Jci1e81jCfTpuc6AAusU58GwTpRCj2LXrqv4OzK3N3pw9AH6ny5K eM_6U0IOBMm29T2ojqxQ- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Wed, 27 Apr 2022 01:33:23 +0000 Received: by hermes--canary-production-ne1-75b69fcf97-h6f5j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 05dc40ebe77b86bded1a115a92ae61b4; Wed, 27 Apr 2022 01:33:17 +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: Tue, 26 Apr 2022 18:33:15 -0700 Cc: jbo@insane.engineer Content-Transfer-Encoding: quoted-printable Message-Id: <000ACC55-4740-4624-A0E3-24AB775929A1@yahoo.com> References: To: joerg@bec.de, FreeBSD Hackers X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4Kp1VM2tfsz3pdh X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=X4j9a+F8; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.65.84 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; 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]; NEURAL_HAM_LONG(-1.00)[-1.000]; 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.84:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; 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-26, at 17:48, Mark Millard wrote: >=20 > =E2=80=A2 Joerg Sonnenberger wrote on > =E2=80=A2 Date: Tue, 26 Apr 2022 23:47:23 UTC : >=20 >> Am Mon, Apr 25, 2022 at 03:39:48PM -0700 schrieb Mark Millard: >>> Basically I avoid inline definitions of: >>>=20 >>> virtual ~type_base(); >>> virtual ~type_int(); >>> virtual ~type_string(); >>=20 >> You only need to ensure that the class has one non-pure non-inline >> function. >=20 > I'm confused at what you are claiming that I did wrong or > described incorrectly for the example at hand. Those are 3 > separate classes each with one virtual method that is not > in line (and that I showed the definitions for later in > the message). No other such functions were involved explicitly > in those 3 classes. >=20 > The gcc class type_info in /usr/local/lib/gcc11/include/c++/typeinfo > describes this implementation detail for type_info itself, as its > example, via: >=20 > class type_info > { > public: > /** Destructor first. Being the first non-inline virtual function, = this > * controls in which translation unit the vtable is emitted. The > * compiler makes use of that information to know where to emit > * the runtime-mandated type_info structures in the new-abi. */ > virtual ~type_info(); > . . . May be the intent is tied to what happens with a one line change, using struct type_base { ~type_base() =3D 0; }; but still having the required definition: interface::type_base::~type_base() {} (implicitly referenced so required in order to link). This makes type_base abstract (not something to potentially directly create). The original example did not have that property, so I did not make my nearly minimal change that way. But using the '=3D 0' as above does produce a working program: # ./test-core=20 t is type_int t is type_string done. >> That's the key function and determines the translation unit >> (and by extension the DSO) where the virtual table and the typeinfo = is >> placed. >=20 > I'm a again confused about where the above disagrees with > what I wrote (in text that you did not quote). >=20 >> If there is no such function, both will be defined as weak >> mergable symbol and that will not result in a unique address when = using >> RTLD_LOCAL. >=20 > I was certainly less detailed about how multiple definitions > are handled. Was that your point? >=20 > Let me know if I've missed some import point --or made some > stupid screwup in what I'd written. >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com