From nobody Tue Aug 08 00:20:29 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 4RKYkT4xngz4pplN for ; Tue, 8 Aug 2023 00:20:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic314-20.consmr.mail.gq1.yahoo.com (sonic314-20.consmr.mail.gq1.yahoo.com [98.137.69.83]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4RKYkS14fsz4brs for ; Tue, 8 Aug 2023 00:20:48 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b=g9iaJM+H; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.69.83 as permitted sender) smtp.mailfrom=marklmi@yahoo.com; dmarc=pass (policy=reject) header.from=yahoo.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691454045; bh=QEsr+Raqg1L3/6KnkiNSradXZxOr3DZ9P9gnQlBFpNc=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=g9iaJM+HtDNrgR1z6A9ytMquLmZV6BYuetpNYuZShrMoLrtT9pOI6j2Su9uZVVtLldvbLvqprsE8vSw5hciVLncEjLTZLZ+BlsIltWc3LPhYAFIYacNZblfyuyNkk6BSECyZOX2o6DdSjIyUJUaqWZ4BvYwmaCChv1r1n3o9g1z6KNFSHQIyLuzMOYDlZd/TJt4emVcm8WdB4Fuu1yaochibTqqAjfOzuTXLqIdsweRR++l7J8bS/QM9rtQICeSN1osovwyh91O5gb2w3KfJdbuWpc6jFLYXj1WrKqbWYc6+7l5FcaEIFzG4DOzdUlTgR6/zm8jZI36VRQUE3495Ig== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1691454045; bh=9rn8M4E/avbzv6fPKif80pbxZ4uvm+P9BSEyLMkczPu=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=W/v2lQ+7J2/x0aKIu/QtLPWPnDkXoth2OlNmr0uDg/o6Ir6qHYFQPIN+KQqUMiYCfkYXejzI3OvVzAZFZXYYHx2CFfKYqK7VIkkp/441N5ZDUh5ehL+RRpl9ihzy3hWIh84xiylAqUGRoeZIW9Y24cOPZYiShSxtFk43kJoluQnxj2xc0Tg7V53+vzyEuydfwboLEna5qG9TDdAe+zfDzlLnY4RIV7PPtKnRsCFEDeOeDo8+cXaSiNAQlDkurpnmII4Kw4qVjGEFn2dRB27Bx8xqfQAin0lplKCsd/xIVH7Z4rytm+4ZzMG9jo6ScF/PglI7efaq7rwQp3OfPYbDRw== X-YMail-OSG: ya3lHH4VM1lGxcFkEAA39iTXhQl9oijPqN2iLzKES8yZd_kCrsyEmpv3b4BoK08 W.68IWlyDFTUxfaikTZg_Yw0OlniIIxLsH5YodTR9QsVZ_T73Df57xzPcbr7RvGsd8hZYVMVQ51. 0LmN4OVGxYoPhwikqK9zNGbGD3v3Am4FujkJz8F0DddrWbxDS5Phac824gy2yqkX1J5YmgH7_MlC dq1XIuuxPahV0_W3bxj34RRbti7jXQnqFB61_Na3Js9MM.Bhoww86ghyG7PA21i8iE5zLcNZnx8o _FHsXOzTfru.WRtrcMRtCfKH7ZGXqCgKA75b_kmvNCyf3.DY5iyftcUUqA7ZU_TQX6hgPknN9GaF rbPVdj79e3_L6kXAQXYwSxUtw1bWUmwNrlb7wUlb4RNV8uEYOo1cVoRM4_XTUI1LICm94rQvdl6g dNmgxPZAgOEPGHgrCKXYZjyfim01eM6TOO73v3aikhu1MGw7KhrndX0c74MZJdhrketLpAVGj6Wc oIEm_NvBJE.zxPKp7NgGHUFd.xOuSjubCKd6rb0_syL3slET2LsizunKC.nVAt6T6kVwWRNpBexz H8yYu.Vam41a2wNfduZJIDfv6FdoUK6eQA9629vlSRCyd7H3_AGCKG_v0RWMsLUR2nKSUou8qPqf PRedHqh2Qeh39FB4CpN5wbWfnGStjf1CZqsLpZDfFbpmZrOfRLHe1GRMmhp9527XPIkQ3lduP01d J91CA.COHjI34AStWv7cJ0WdKSXHgEUSts71Ex7DS1JUz5qoNzmqbBc88tN8g3e_SPT6rlF4jte2 .kohmhHD7umyfd0yB4N6wqDgrruSJO.cNDC7MKgHjZ6MAnnivOLne0YBZYl8M9JtIo_C.jub5XwV 6w3LPa92x6vJ5P1VBhTsaOMjG1BBjzyEI14nXUecU3c5u9YjcQNzzk5gwSUNt7PyN_ubbczZZ_ip DqqWm.o5yuz8wQ93p9tN3hqPWObrLmGsn9SP87CgIHalLd1FpKdkOLdnxH_igyfcmXpiHVCy_D4l a9mO05HehlfYaGIVcPzW82ErVkzcJNsDVrWTWik3yIvZCs6jlXvjkFThml7kplthbBw58DH.Kho9 3fUxbyHs1w3.795rzcA6k62YVzfZF2Sqx4Jn4Tygc3RoIQAcCfYaynCe4JxKvXVzZxOexM3oAKzt .IcF_01QliQQPufqxlCX7MsYZnSNGxlhHf_ODnJjORrOq7GLWkFLaSddZ6ZvHlC8TwUggT7mNl2x 6xSF4qG1vtyOU0WrXb.iAmUqCNPs2kNyGJlv2DRsgRZ.uU.2IQZLt2RZQWN3cWyDBp96WgJ5XiIZ N0VJ5f6Bot1gTGXciv_vtwzAkdYMtp_Kjun2uU3UJab2HG_iUu_JrklPYaLn0uy0oJVohvEpPTik 98B5vEbFEHvA4FILkq8GHMAb5Fp3mvv0eVER6hLix56Z4m6OEh0FkpuCdgIiK_wAKrh8lcMzdzXy NvFrQ8kFYJrA2bEI3hbaTyVjayZDkGer4BKqk1uRclhz6lWX9X9Jf95Wh8ON.9jWYTFO_h4.NKI6 Z.HvecWZvRxzuHzVSTC_Ni4X6qPtWfjQXzamO5EDAurBANlJnjKA6qpm8G_3H_KruZA7.KvRvqw6 qwiiSsj.CyK4vQxSoXcZqNLFbYL5lOeH7kOV5Bq8BTWp6Q.tHtnH9IwlbEm.UUEDCTjuEkPsBXhL mnRAzn64BQc0MRkcTx4Nh1HApc6WaFjIkHToqoxREZg5c_3vd16j1aFh44SUCreJ9nR.WSpHMwd4 1k0_QEEa2GLC6LLjbzpIOOWPqRzgQGCQjSydHQ9eLwghIGUrbM0HBNAxWgLPsWE9rQWWIZFUzk7k SIDGV5XpCAbiCxmF603O7N_TN7dPamMcrEdsOodXkXC0wncv54IrAtN3Iu274pBnWb2lX7r68B9m 4MtMZVFW2Gw1Qyp9wljw0hXAppGrviveegaxunLlb0sw5rt8lf3D6uxKz8xEGzgvqkLZ_HtaI1qG QuwimUxHbefnFxNy.PC4e8LY..a9fYJnRa_MSa1IQGe0PiVhimR6AAeJoQBv4gnw6DuhBK6ds0gx KrKsjFdArw_53f54NunrF3iIV_lYt9IRzaK9DY7qWljvdKDfqbVoY0gaS0v1cYFuklICdg8TYYVu T._fS4Mb8bOID7ve4yCQNI0UCkZQPQG2p8v_ebqOUglRf4.uYel2jtUxqrFqumYeBr67DnvzJTUk .yI623zHIQFv32bLclzuF6CvYs5_4QarD4xAvoRlSQQosJVVKBEnGlHcvaly0fldsdey_Xot6aiq y X-Sonic-MF: X-Sonic-ID: d1ef7198-3137-42d3-9185-51c72f03a641 Received: from sonic.gate.mail.ne1.yahoo.com by sonic314.consmr.mail.gq1.yahoo.com with HTTP; Tue, 8 Aug 2023 00:20:45 +0000 Received: by hermes--production-ne1-7b767b77cc-swgdr (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID dd743be0b72b0e44dad02c05872d906e; Tue, 08 Aug 2023 00:20:41 +0000 (UTC) Content-Type: text/plain; charset=utf-8 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: Mark Millard In-Reply-To: Date: Mon, 7 Aug 2023 17:20:29 -0700 Cc: toolchain@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Christoph Moench-Tegeder X-Mailer: Apple Mail (2.3731.700.6) X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.69)[-0.695]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; MV_CASE(0.50)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; MIME_GOOD(-0.10)[text/plain]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MLMMJ_DEST(0.00)[toolchain@freebsd.org]; ARC_NA(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[98.137.69.83:from]; BLOCKLISTDE_FAIL(0.00)[98.137.69.83:server fail]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.69.83:from]; DKIM_TRACE(0.00)[yahoo.com:+]; FREEMAIL_FROM(0.00)[yahoo.com]; TO_DN_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_TLS_LAST(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_TWO(0.00)[2] X-Spamd-Bar: --- X-Rspamd-Queue-Id: 4RKYkS14fsz4brs On Aug 6, 2023, at 14:40, Christoph Moench-Tegeder = wrote: > Hi, > while updating our kicad port I'm facing major problems with > dynamic_cast on FreeBSD 13.2/amd64 - issues are seen with both base > clang and devel/llvm15, and I guess we're rather talking libc++ here. > Specifically, dynamic_cast fails when casting from a base to a derived > type ("downcast" as in C++ lingo?). I already know about = "--export-dynamic" > but that does not help here - and as far as I read other platform's > build scripts, no other platform requires any kind of "special > handling" for dynamic_cast to work - what am I holding wrong here, > or what's missing from the picture? >=20 > But for the gory details: here's exhibit A, the code in question: > = https://gitlab.com/kicad/code/kicad/-/blob/7.0/include/settings/settings_m= anager.h?ref_type=3Dheads#L110 > That m_settings is declared as > std::vector> m_settings; > and contains objects of types derived from JSON_SETTINGS (there's > the intermediate type APP_SETTINGS_BASE, and specific types like > KICAD_SETTINGS etc.) The function GetAppSettings() is > called, so that the find_if() in there should return that one > KICAD_SETTINGS object from m_settings as only that should > satisfy dynamic_cast - but in fact, no object is found. > That also happens if I unwind the find_if() and build a simple > for-loop (as one did, back in the last millenium). >=20 > If I point gdb at that m_settings (with "set print object on" and > "set print vtbl on"), I do find my KICAD_SETTINGS object smack > in the middle of m_settings: >=20 > (gdb) print *(m_settings[5]) > $18 =3D (KICAD_SETTINGS) { =3D { =3D = { > _vptr$JSON_SETTINGS =3D 0xed1578 , >=20 > so the type info isn't totally lost here. >=20 > When testing this, CXXFLAGS passed via cmake are rather minimal, > like "-std=3Dc++17 -O0 -fstack-protector-strong -fno-strict-aliasing > -Wl,--export-dynamic" (and cmake sprinkles some "-g" and a few > other standard flags into the mix), LDFLAGS ("CMAKE_...LINKER_FLAGS") > are set up similarly) (I have some inkling that these cmakefiles > in this project are not always very strict on compiling vs linking). >=20 > I had similar issues with dynamic_cast before, as witnessed here: > = https://cgit.freebsd.org/ports/tree/cad/kicad/files/patch-job_use_dynamic_= cast_for_updating > but now that I'm facing the current problem, I have a strong feeling > that my diagnosis back than was rather bullshit. >=20 > Help? May be the following type of thing from=20 https://www.gnu.org/software/gcc/java/faq.html might be relevant to your context? I can not tell from the description. (A different ABI could have differing details. But the below could be at least suggestive of considerations.) dynamic_cast, throw, typeid don't work with shared libraries The new C++ ABI in the GCC 3.0 series uses address comparisons, rather = than string compares, to determine type equality. This leads to better = performance. Like other objects that have to be present in the final = executable, these std::type_info objects have what is called vague = linkage because they are not tightly bound to any one particular = translation unit (object file). The compiler has to emit them in any = translation unit that requires their presence, and then rely on the = linking and loading process to make sure that only one of them is active = in the final executable. With static linking all of these symbols are = resolved at link time, but with dynamic linking, further resolution = occurs at load time. You have to ensure that objects within a shared = library are resolved against objects in the executable and other shared = libraries. =E2=80=A2 For a program which is linked against a shared library, no = additional precautions are needed. =E2=80=A2 You cannot create a shared library with the "-Bsymbolic" = option, as that prevents the resolution described above. =E2=80=A2 If you use dlopen to explicitly load code from a shared = library, you must do several things. First, export global symbols from = the executable by linking it with the "-E" flag (you will have to = specify this as "-Wl,-E" if you are invoking the linker in the usual = manner from the compiler driver, g++). You must also make the external = symbols in the loaded library available for subsequent libraries by = providing the RTLD_GLOBAL flag to dlopen. The symbol resolution can be = immediate or lazy. Template instantiations are another, user visible, case of objects with = vague linkage, which needs similar resolution. If you do not take the = above precautions, you may discover that a template instantiation with = the same argument list, but instantiated in multiple translation units, = has several addresses, depending in which translation unit the address = is taken. (This is not an exhaustive list of the kind of objects which = have vague linkage and are expected to be resolved during linking & = loading.) If you are worried about different objects with the same name colliding = during the linking or loading process, then you should use namespaces to = disambiguate them. Giving distinct objects with global linkage the same = name is a violation of the One Definition Rule (ODR) [basic.def.odr]. For more details about the way that GCC implements these and other C++ = features, please read the C++ ABI specification. Note the std::type_info = objects which must be resolved all begin with "_ZTS". Refer to ld's = documentation for a description of the "-E" & "-Bsymbolic" flags. =3D=3D=3D Mark Millard marklmi at yahoo.com