From nobody Thu Aug 10 17:38:26 2023 X-Original-To: toolchain@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 4RMDg728Zgz4ppYW for ; Thu, 10 Aug 2023 17:38:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4RMDg71cKkz4QLy; Thu, 10 Aug 2023 17:38:43 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691689123; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/5VZN3q7pqGYltwpdobCwHGV+HO70B+u/L0x8yfWCp8=; b=QX3HS18/uPZSJbxI0PuRHEHFVobkr+W+iAtFTHolMPYd/xXXu46s4y/QgzCSjRHSZIWSTf I2rgS75OS2JPUvZoYKW4U0M8U/lrIzI+nFmCxYNjoaG70Hvbl5UIkXaVXF+axSSyK8fK5h u2Ei8bShyCLHF867qcVOSjS40nGanGpMapVjt8kKX2jPImpAmtmzHvKZa0RNuWFIceeTgc irJDc68V1giIZVryYcwxiBbBHzXqw0R6dAyp7JmFea6agJvp7ohl+esTfMB52BeFaHfsfp qvm0rzO6XeqDRJWAhNYDoLf43fUopH9saFn94QohLXlr9M+0INvSyinSJsZkFA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1691689123; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=/5VZN3q7pqGYltwpdobCwHGV+HO70B+u/L0x8yfWCp8=; b=Nvwv/3kpNQwHaaNRl7FwCMWgjQ1H3AEe6sTca9o27QgrNdhpkoNqnOOueVvHMlGFzOipdt mZP9jNocWDjvv9bXaS5LVnFsJrcEW0VDujH9QEDu6uVY/zD+VNHMJjKmkqiWvI0QJUEIyX V0Bayc+lLjTlgXw+K6WNiVXHoKO0NSiFT/UhYAK5Rf907ro7c36dG8W2RgWhjiPmrzqbrK IjhwWa0CnH5VUl3K7val7q8dQwf19fKxz0/pylXGK2EgVrJhUCm2iznh2OYH7lcbGnZfcN LACRXudTu/hWiNv7QyOL2KQcRlYAEMcvkAPBYr+2+JDAT2+mLCjQ1e3ak9Z6RA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1691689123; a=rsa-sha256; cv=none; b=jTGWEV2KKbz+e9vpblP2pmLWjGsF0sZQPiAFWBn+eCNBZtpCy1OHuUhJeAGXo7/7EK72U1 k4Jzfad0L5zwu/8IHrpWR/61royDGN19nvb8aCZN+9liFEuG+/eWywdZgM565kPGt27/e4 NNIgPWEahQRUZ5PXrF/s2+ylKLXs2AINC0xe+EBakYBQkfP7xFvdvEfPuRlEJ/ggrOpmAk xi7UAKXzYzMJQl7dXIxibmY88hMKOc6V9nbQVOBz46aXOKsNKpj3OBwmNx+qsOpqfaTm/9 CgfOgdyg4QleNP2UiGRia490gfHleDDsAD4wx3GQaKwERmUamb0nuZkCNPxUHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id 4RMDg673KVz7x1; Thu, 10 Aug 2023 17:38:42 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtpclient.apple (longrow.home.andric.com [192.168.0.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id C089C59B6B; Thu, 10 Aug 2023 19:38:41 +0200 (CEST) Content-Type: multipart/signed; boundary="Apple-Mail=_3A625569-74F1-420F-B0B5-001ED67E0558"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Maintenance of FreeBSD s integrated toolchain List-Archive: https://lists.freebsd.org/archives/freebsd-toolchain List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: c++: dynamic_cast woes From: Dimitry Andric In-Reply-To: <6E31D6F9-8E9D-42FE-9D14-2A80EBD2B912@FreeBSD.org> Date: Thu, 10 Aug 2023 19:38:26 +0200 Cc: Mark Millard , toolchain@freebsd.org Message-Id: <2AEA9921-5943-475C-B307-C5020BBE3F32@FreeBSD.org> References: <6B6A7C9C-8F82-443D-BBC3-B2263FEAFD79@FreeBSD.org> <6E31D6F9-8E9D-42FE-9D14-2A80EBD2B912@FreeBSD.org> To: Christoph Moench-Tegeder X-Mailer: Apple Mail (2.3731.700.6) --Apple-Mail=_3A625569-74F1-420F-B0B5-001ED67E0558 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 10 Aug 2023, at 00:25, Dimitry Andric wrote: >=20 > On 9 Aug 2023, at 00:29, Christoph Moench-Tegeder = wrote: >>=20 >> ## Dimitry Andric (dim@FreeBSD.org): >>=20 >>> Yes, this is a typical problem when type info is replicated across >>> dynamic library boundaries. The best thing to prevent this is to >>> ensure that the key functions for a class (typically constructors >>> and destructors) are only in one translation unit (object file), >>> and that object file is only in one .so file. >>=20 >> As FreeBSD is basically unsupported from upstream, this sounds >> like I'm in for quite a bit of fun here. Well. >=20 > FWIW, it took quite a while (kicad has LOTS of dependencies!), but I > built kicad and it looks like I can reproduce the original problem, > after disabling the static-cast-patch. So I will investigate it a bit > further. It looks like KiCad is violating the One Definition Rule (ODR) all over the place... So it will not really be trivial to fix, unfortunately. The problem is that C++ virtual tables and type information gets copied into *both* the kicad main binaries (kicad/kicad-cli), and the plugins (_*.kiface). This is due to the way the binaries and plugins get linked, namely to a bunch of static libraries containing the common kicad parts (libcommon.a, libscripting.a, etc). Classes like KICAD_SETTINGS or JOB_EXPORT_SCH_PDF are declared in header files, and usually their vtables and type_info get emitted into one particular object file, so for instance the vtable and type_info for KICAD_SETTINGS gets emitted into kicad_settings.cpp.o. However, kicad_settings.cpp.o gets archived into libcommon.a, and this libcommon.a gets linked into both the main binaries *and* the .kiface plugins! It means there are now multiple copies of the same virtual table and type_info, and that is an explicit violation of the ODR. The behavior at runtime is now officially undefined, but in practice it is implementation-defined: some implementations like libstdc++ work around it, by doing a deep comparison of type_info when casting dynamically. Others, like libcxxrt and libc++abi, only compare the addresses of the different copies of the same type_info, and in such cases the comparison will fail. The correct way to fix this is by making sure the common code gets put into one shared libary, which explicitly exports all the required symbols (so using __dllexport on Windows, and non-hidden visibility on ELF platforms). Only then can you make sure the ODR is not violated. But this would entail a pretty big refactoring for KiCad... :) -Dimitry --Apple-Mail=_3A625569-74F1-420F-B0B5-001ED67E0558 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.2 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCZNUgkgAKCRCwXqMKLiCW o8XtAKCUmE8n5D2nIRAAxaNreikAS8GkDwCfa8ECarmk2KpgxLhl/k+deG0j35I= =/q9n -----END PGP SIGNATURE----- --Apple-Mail=_3A625569-74F1-420F-B0B5-001ED67E0558--