From nobody Fri Mar 04 18:25:06 2022 X-Original-To: dev-commits-src-branches@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 46F3019FDD66 for ; Fri, 4 Mar 2022 18:25:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 4K9GVh1NbPz4fSf; Fri, 4 Mar 2022 18:25:16 +0000 (UTC) (envelope-from dim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646418316; 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=eXQAQH7gbMBH6Scdt5fzfpvnePr7n4MAmsaqzj2NpCY=; b=cMU8LckQF/dv6DxDeXN15HwrOcI2AGbHlDUCMern04a4RjDyzqi5VI7neToGn8gN2kgqrS 5sf5LkAnjlzQMuLsC0Qq4ncfAXKPJtREah0P9kkVuFRBRVm5RYa8KHlHLiiQ4yUWLubInK yLC/O1QpXCB9zibuXuuLhROTgfXNpZQvMoPeCtx1fifKL27yQdd1xyz/S0sW631Wm+OmZl 3aSYLFU+gFCdPujY3UlsiK7i8hHNVYZs3pcw5aaPlIvZuK+RhyBPzCvFJIgWK35euEFLlS 4AIYRCvRwn0kCdX/LaVjgvrMzfofU6qxJDq6baGHd3KPwGq6wVkXrOmc1CbI+A== Received: from tensor.andric.com (tensor.andric.com [87.251.56.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tensor.andric.com", Issuer "R3" (verified OK)) (Authenticated sender: dim) by smtp.freebsd.org (Postfix) with ESMTPSA id E94A076D5; Fri, 4 Mar 2022 18:25:15 +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 DE6DA45F3D; Fri, 4 Mar 2022 19:25:13 +0100 (CET) Content-Type: multipart/signed; boundary="Apple-Mail=_5FD63159-A1F5-48DC-BC9F-BEE169A98DCF"; protocol="application/pgp-signature"; micalg=pgp-sha1 List-Id: Commits to the stable branches of the FreeBSD src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-branches List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-branches@freebsd.org X-BeenThere: dev-commits-src-branches@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 15.0 \(3693.60.0.1.1\)) Subject: Re: git: b2127b6f1ae2 - stable/13 - Install unwind.h into /usr/include From: Dimitry Andric In-Reply-To: Date: Fri, 4 Mar 2022 19:25:06 +0100 Cc: Tomoaki AOKI , Ed Maste , dev-commits-src-branches@freebsd.org Message-Id: <6E5AD771-3140-480A-BF20-95B8E8A27189@FreeBSD.org> References: <20220303224535.a0cca57e1f033e930a7f8f9d@dec.sakura.ne.jp> <3166E99F-1616-40D9-BD8B-D18E8104D6FF@FreeBSD.org> To: John Baldwin X-Mailer: Apple Mail (2.3693.60.0.1.1) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1646418316; 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=eXQAQH7gbMBH6Scdt5fzfpvnePr7n4MAmsaqzj2NpCY=; b=F3v9q3oJ+ihkm9hGtmcRboQs0wLoisj/X+nXOzK+P1PVJPRfF62e0foRJkxEht+vCN+uLR QNcH0BUvygZsiHypoWa1WxzYuRRv6WOglkIKrW7ky+DrOw4/+pPr/nHRhZpi/5LGFIfT8r s7bchq4ualBMQR6p6oTioLgOYFSOnQfs52Z9zYLnibP8tZwvdxMqbIFWmcnoxJ7fEApdQ0 MM7QNfG6BKt2Di9K9pr0/W+/1E3zn9NHSSVHmLnJsH4azVSs8wIyhmDLBqy0dIQTQfHbVO B/CnTIpGD+TgRa0MVH2zAt9u1ub7JKNj+if0ctsR8b8QYfIVGzlkR3q3nMR1Wg== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1646418316; a=rsa-sha256; cv=none; b=YNXMMi12E0An02oWE9mzEq2UUWIDXssfuKnYZZsst7OIlP1U1avLTb4v41+cTlZFYHQ4NE fgMfO/8e7JSy62/PscpQQ1xrniClZ3gryFJ7pU/ovJrLQDKl0BiNm0DxEmpOjNazWxxBlk ioSaaTI6PJaBZ/1OcwxDaTmi+fGzRIuXeOrwNe8IyM4GjPC7l048MsbRrL0vTli7t0FM+t 6oCmCZOanvcrC9AGxpU3w6qyV8QV2SYs3/XIR+ZEMeBpcNopl4kIy6wUU0rwy8cyoa77St KLtxZ2NFTpD2TQM2/wdOww5TpnF71QxM4wyUz0felaHgAJcer4WD+yKXGy4GPQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_5FD63159-A1F5-48DC-BC9F-BEE169A98DCF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 3 Mar 2022, at 21:30, John Baldwin wrote: >=20 > On 3/3/22 10:08 AM, Dimitry Andric wrote: >> I can't even get to building libreoffice, as all the openjdk ports = fail to build, with DTrace errors: >> dtrace: failed to compile script = /wrkdirs/share/dim/ports/java/openjdk12/work/openjdk-jdk12u-jdk-12.0.2-10-= 4/build/bsd-x86_64-server-release/hotspot/variant-server/support/dtrace/ho= tspot.h.d: "/u >> /mbuf.d", line 1: failed to copy type of 'm_data': Type information = is in parent and unavailable >> * For target hotspot_variant-server_gensrc_dtracefiles_hotspot_jni.h: >> dtrace: failed to compile script = /wrkdirs/share/dim/ports/java/openjdk12/work/openjdk-jdk12u-jdk-12.0.2-10-= 4/build/bsd-x86_64-server-release/hotspot/variant-server/support/dtrace/ho= tspot_jni.h.d: >> race/mbuf.d", line 1: failed to copy type of 'm_data': Type = information is in parent and unavailable >> * For target hotspot_variant-server_gensrc_dtracefiles_hs_private.h: >> dtrace: failed to compile script = /wrkdirs/share/dim/ports/java/openjdk12/work/openjdk-jdk12u-jdk-12.0.2-10-= 4/build/bsd-x86_64-server-release/hotspot/variant-server/support/dtrace/hs= _private.h.d: >> ace/mbuf.d", line 1: failed to copy type of 'm_data': Type = information is in parent and unavailable >> It seems there is no way to disable DTrace in the openjdk ports, so = I'm a little stuck on this. >> Maybe it is possible to build libreoffice without Java support? But = then I don't know if I will get the same error as you're getting. >> -Dimitry >=20 > It might also be helpful to not re-use the same PR for multiple = issues. (When I > first started reading the PR it was hard to understand why unwind.h = had broken > openjpeg.) >=20 > If I have read it correctly, some build tool (gengal?) is now = segfaulting during > the build. My initial guess is that the build tool decided to alter = its behavior > based on a configure-type check finding unwind.h and enabling some bit = of > functionality that previously was not enabled. So here's what apppears to be happening: Core was generated by = `/wrkdirs/share/dim/ports/editors/libreoffice/work/libreoffice-7.3.0.3/ins= tdir/pr'. Program terminated with signal SIGSEGV, Segmentation fault. Address not mapped to object. #0 std::type_info::name (this=3D0x0) at = /usr/include/c++/v1/typeinfo:318 318 return __impl::__type_name_to_string(__type_name); this=3DNULL, that's never good. :) (gdb) bt #0 std::type_info::name (this=3D0x0) at = /usr/include/c++/v1/typeinfo:318 #1 gcc3::deleteException (pExc=3D0x87b5aff00) at bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx:139 #2 0x000000082c2e92e7 in __cxa_free_exception ( thrown_exception=3D0x87b5aff00) at = /share/dim/src/freebsd/llvm-14-update/contrib/libcxxrt/exception.cc:627 #3 0x000000082a4e6a15 in FileExists (rURL=3D...) at svx/source/gallery2/galmisc.cxx:214 #4 0x000000082a4f5871 in = GalleryBinaryStorageLocations::ImplGetURLIgnoreCase (rURL=3D...) at svx/source/gallery2/gallerybinarystoragelocations.cxx:28 #5 0x000000082a4f4ac7 in GalleryBinaryEngineEntry::CreateUniqueURL ( rBaseURL=3D..., aURL=3D...) at svx/source/gallery2/gallerybinaryengineentry.cxx:56 #6 0x000000082a4e2543 in GalleryThemeEntry::GalleryThemeEntry ( this=3D0x87b56b4a0, bCreateUniqueURL=3Dtrue, rBaseURL=3D..., = rName=3D..., _bReadOnly=3Dfalse, _bNewFile=3Dfalse, _nId=3D0, _bThemeNameFromResource=3D) at svx/source/gallery2/gallery1.cxx:123 #7 0x000000082a4e4c20 in Gallery::CreateTheme (this=3D0x87a2fffc0, rThemeName=3D...) at svx/source/gallery2/gallery1.cxx:582 #8 0x0000000000207105 in createTheme (aThemeName=3D..., aGalleryURL=3D..., aDestDir=3D..., rFiles=3D..., bRelativeURLs=3D) at svx/source/gengal/gengal.cxx:72 #9 (anonymous namespace)::GalApp::Main ( this=3D0x20db98 ) at svx/source/gengal/gengal.cxx:294 #10 0x000000082e571d3e in ImplSVMain () at vcl/source/app/svmain.cxx:199 #11 0x000000082e5730aa in SVMain () at vcl/source/app/svmain.cxx:231 #12 0x000000000020a5df in sal_main () at vcl/source/salmain/salmain.cxx:34 #13 main (argc=3D, argv=3D) at vcl/source/salmain/salmain.cxx:29 (gdb) up #1 gcc3::deleteException (pExc=3D0x87b5aff00) at bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx:139 139 OUString unoName( toUNOname( header->exceptionType->name() ) = ); (gdb) print *header $7 =3D {referenceCount =3D 0, exceptionType =3D 0x0, exceptionDestructor =3D 0x825fc9ad0 , unexpectedHandler =3D 0x875b3a220 , terminateHandler =3D 0x82c2e9510 , nextException =3D 0x83041e0e0 , handlerCount =3D 0, handlerSwitchValue =3D 0, actionRecord =3D 0x0, languageSpecificData =3D 0x82a216508 "\003}\004", catchTemp =3D 0x82a2164cc, adjustedPtr =3D 0x0, unwindHeader =3D { exception_class =3D 5138137972254386944, exception_cleanup =3D 0x82c2e9990 = , private_1 = =3D 0, private_2 =3D 34912978464}} The problem is that header->exceptionType is NULL. This appears to be because the offset for 'header' is 8 bytes off; there is an assert in except.cxx that checks this, but of course it gets compiled out for release mode: assert(header->exceptionDestructor =3D=3D &deleteException); (gdb) print header->exceptionDestructor $8 =3D (void (*)(void *)) 0x825fc9ad0 (gdb) print &gcc3::deleteException $10 =3D (void (*)(void *)) 0x875b3a220 So those definitely don't match, the header is in the wrong spot. If you shift it 8 bytes up, it starts looking better: (gdb) print *(const __cxa_exception *)((const char *)header + 8) $11 =3D {referenceCount =3D 0, exceptionType =3D 0x825fc9ad0 , exceptionDestructor =3D 0x875b3a220 , unexpectedHandler =3D 0x82c2e9510 , terminateHandler =3D 0x83041e0e0 , nextException =3D 0x0, handlerCount =3D 0, handlerSwitchValue =3D 0, actionRecord =3D 0x82a216508 "\003}\004", languageSpecificData =3D 0x82a2164cc = "\377\233M\001\061\067\021\243\003\aP\t\373\002\aY\025\334\002\az\003\261\= 002\t\211\001\003\251\002\t\310\001\020\271\002\a\356\002\003\363\002\t\21= 5\003\003\233\003\t\220\003Z", catchTemp =3D 0x0, adjustedPtr =3D = 0x87b5aff00, unwindHeader =3D { exception_class =3D 35100989840, exception_cleanup =3D 0x0, private_1 =3D 34912978464, private_2 =3D 36429320480}} E.g. there the exceptionDestructor field exactly matches the address of gcc3::deleteException. Interestingly, in except.cxx there is a large block with an explanatory comment, which tells how this might be caused, but it is *only* enabled for libc++abi, apparently: #if defined _LIBCPPABI_VERSION // detect libc++abi // First, the libcxxabi commit // = // "[libcxxabi] Align unwindHeader on a double-word boundary" = towards // LLVM 5.0 changed the size of __cxa_exception by adding // // __attribute__((aligned)) // // to the final member unwindHeader, on x86-64 effectively adding a = hole of // size 8 in front of that member (changing its offset from 88 to = 96, // sizeof(__cxa_exception) from 120 to 128, and = alignof(__cxa_exception) // from 8 to 16); the "header1" hack below to dynamically determine = whether we run against a // LLVM 5 libcxxabi is to look at the exceptionDestructor member, = which must // point to this function (the use of __cxa_exception in = fillUnoException is // unaffected, as it only accesses members towards the start of the = struct, // through a pointer known to actually point at the start). The = libcxxabi commit // = // "Insert padding before the __cxa_exception header to ensure the = thrown" in LLVM 6 // removes the need for this hack, so the "header1" hack can be = removed again once we can be // sure that we only run against libcxxabi from LLVM >=3D 6. // // Second, the libcxxabi commit // = // "[libcxxabi] Insert padding in __cxa_exception struct for = compatibility" in LLVM 10 changed // the layout of the start of __cxa_exception to // // [8 byte void *reserve] // 8 byte size_t referenceCount // // so the "header2" hack below to dynamically determine whether we = run against a LLVM >=3D 10 // libcxxabi is to look whether the exceptionDestructor (with its = known value) has increased its // offset by 8. As described in the definition of __cxa_exception // (bridges/source/cpp_uno/gcc3_linux_x86-64/share.hxx), the = "header2" hack (together with the // "#if 0" in the definition of __cxa_exception and the = corresponding hack in fillUnoException) // can be dropped once we can be sure that we only run against new = libcxxabi that has the // reserve member. if (header->exceptionDestructor !=3D &deleteException) { auto const header1 =3D reinterpret_cast<__cxa_exception const = *>( reinterpret_cast(header) - 8); if (header1->exceptionDestructor =3D=3D &deleteException) { header =3D header1; } else { auto const header2 =3D reinterpret_cast<__cxa_exception = const *>( reinterpret_cast(header) + 8); if (header2->exceptionDestructor =3D=3D &deleteException) { header =3D header2; } else { assert(false); } } } #endif I remember that we have had an earlier issue which was related to this shifting up and down by 8 bytes, as there is a part in libcxxrt's exception.cc about this: #ifdef __LP64__ /** * There's an ABI bug in __cxa_exception: unwindHeader requires 16-byte * alignment but it was broken by the addition of the referenceCount. * The unwindHeader is at offset 0x58 in __cxa_exception. In order to = keep * compatibility with consumers of the broken __cxa_exception, = explicitly add * padding on allocation (and account for it on free). */ static const int exception_alignment_padding =3D 8; #else static const int exception_alignment_padding =3D 0; #endif However, previously with libcxxrt's own unwind.h headers installed, libreoffice didn't need to do anything special to get at the correct header address. For some reason, with the libunwind headers instead, it now gets shifted by 8 bytes. I think we are having a case of kludges upon kludges upon hacks, which is now falling apart... :-) In any case, if I unconditionally enable the "#if defined _LIBCPPABI_VERSION // detect libc++abi" block in except.cxx, it does detect the exception header successfully, the gengal.bin command does not crash anymore, and the whole libreoffice build succeeds. The libreoffice binaries even run OK, though I only did light testing, like opening a doc file and messing around with it a little bit. But I'm not sure if it is the solution we want. Maybe we should again put in some sort of compat hack, to make the libunwind/libcxxrt combination work for this scenario? (I think libreoffice is one of the few applications that calls __cxa_throw directly, with its own deleter function...) -Dimitry --Apple-Mail=_5FD63159-A1F5-48DC-BC9F-BEE169A98DCF 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 iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYiJZggAKCRCwXqMKLiCW o7YaAJ4hpIgdiXpPZ1RBgCRFYsr9KRsIhgCg2dI3QJ+XLf4gCvfbzeEBAN/0e8Y= =Z7RM -----END PGP SIGNATURE----- --Apple-Mail=_5FD63159-A1F5-48DC-BC9F-BEE169A98DCF--