From nobody Sat Mar 05 02:36:13 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 9426E19F5F92 for ; Sat, 5 Mar 2022 02:36:17 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from www121.sakura.ne.jp (www121.sakura.ne.jp [153.125.133.21]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4K9TPD3hCjz4k3n; Sat, 5 Mar 2022 02:36:16 +0000 (UTC) (envelope-from junchoon@dec.sakura.ne.jp) Received: from kalamity.joker.local (123-1-31-137.area1b.commufa.jp [123.1.31.137]) (authenticated bits=0) by www121.sakura.ne.jp (8.16.1/8.16.1/[SAKURA-WEB]/20201212) with ESMTPA id 2252aDXG013582; Sat, 5 Mar 2022 11:36:14 +0900 (JST) (envelope-from junchoon@dec.sakura.ne.jp) Date: Sat, 5 Mar 2022 11:36:13 +0900 From: Tomoaki AOKI To: Dimitry Andric Cc: John Baldwin , Ed Maste , dev-commits-src-branches@freebsd.org Subject: Re: git: b2127b6f1ae2 - stable/13 - Install unwind.h into /usr/include Message-Id: <20220305113613.7760bb3845cda1c04707fb34@dec.sakura.ne.jp> In-Reply-To: <6E5AD771-3140-480A-BF20-95B8E8A27189@FreeBSD.org> References: <20220303224535.a0cca57e1f033e930a7f8f9d@dec.sakura.ne.jp> <3166E99F-1616-40D9-BD8B-D18E8104D6FF@FreeBSD.org> <6E5AD771-3140-480A-BF20-95B8E8A27189@FreeBSD.org> Organization: Junchoon corps X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; amd64-portbld-freebsd13.0) 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 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4K9TPD3hCjz4k3n X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of junchoon@dec.sakura.ne.jp has no SPF policy when checking 153.125.133.21) smtp.mailfrom=junchoon@dec.sakura.ne.jp X-Spamd-Result: default: False [-1.60 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; MV_CASE(0.50)[]; FROM_HAS_DN(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[sakura.ne.jp]; AUTH_NA(1.00)[]; HAS_ORG_HEADER(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; MLMMJ_DEST(0.00)[dev-commits-src-branches]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:7684, ipnet:153.125.128.0/18, country:JP]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[123.1.31.137:received] X-ThisMailContainsUnwantedMimeParts: N On Fri, 4 Mar 2022 19:25:06 +0100 Dimitry Andric wrote: > On 3 Mar 2022, at 21:30, John Baldwin wrote: > > > > 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/hotspot.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/hotspot_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 > > > > 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.) > > > > 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/instdir/pr'. > Program terminated with signal SIGSEGV, Segmentation fault. > Address not mapped to object. > #0 std::type_info::name (this=0x0) at /usr/include/c++/v1/typeinfo:318 > 318 return __impl::__type_name_to_string(__type_name); > > this=NULL, that's never good. :) > > (gdb) bt > #0 std::type_info::name (this=0x0) at /usr/include/c++/v1/typeinfo:318 > #1 gcc3::deleteException (pExc=0x87b5aff00) > at bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx:139 > #2 0x000000082c2e92e7 in __cxa_free_exception ( > thrown_exception=0x87b5aff00) > at /share/dim/src/freebsd/llvm-14-update/contrib/libcxxrt/exception.cc:627 > #3 0x000000082a4e6a15 in FileExists (rURL=...) > at svx/source/gallery2/galmisc.cxx:214 > #4 0x000000082a4f5871 in GalleryBinaryStorageLocations::ImplGetURLIgnoreCase (rURL=...) > at svx/source/gallery2/gallerybinarystoragelocations.cxx:28 > #5 0x000000082a4f4ac7 in GalleryBinaryEngineEntry::CreateUniqueURL ( > rBaseURL=..., aURL=...) > at svx/source/gallery2/gallerybinaryengineentry.cxx:56 > #6 0x000000082a4e2543 in GalleryThemeEntry::GalleryThemeEntry ( > this=0x87b56b4a0, bCreateUniqueURL=true, rBaseURL=..., rName=..., > _bReadOnly=false, _bNewFile=false, _nId=0, > _bThemeNameFromResource=) > at svx/source/gallery2/gallery1.cxx:123 > #7 0x000000082a4e4c20 in Gallery::CreateTheme (this=0x87a2fffc0, > rThemeName=...) at svx/source/gallery2/gallery1.cxx:582 > #8 0x0000000000207105 in createTheme (aThemeName=..., > aGalleryURL=..., aDestDir=..., rFiles=..., > bRelativeURLs=) at svx/source/gengal/gengal.cxx:72 > #9 (anonymous namespace)::GalApp::Main ( > this=0x20db98 ) > 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=, argv=) > at vcl/source/salmain/salmain.cxx:29 > (gdb) up > #1 gcc3::deleteException (pExc=0x87b5aff00) > at bridges/source/cpp_uno/gcc3_linux_x86-64/except.cxx:139 > 139 OUString unoName( toUNOname( header->exceptionType->name() ) ); > (gdb) print *header > $7 = {referenceCount = 0, exceptionType = 0x0, > exceptionDestructor = 0x825fc9ad0 , > unexpectedHandler = 0x875b3a220 , > terminateHandler = 0x82c2e9510 , > nextException = 0x83041e0e0 , handlerCount = 0, > handlerSwitchValue = 0, actionRecord = 0x0, > languageSpecificData = 0x82a216508 "\003}\004", > catchTemp = 0x82a2164cc, adjustedPtr = 0x0, unwindHeader = { > exception_class = 5138137972254386944, > exception_cleanup = 0x82c2e9990 , private_1 = 0, private_2 = 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 == &deleteException); > > (gdb) print header->exceptionDestructor > $8 = (void (*)(void *)) 0x825fc9ad0 > (gdb) print &gcc3::deleteException > $10 = (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 = {referenceCount = 0, > exceptionType = 0x825fc9ad0 , > exceptionDestructor = 0x875b3a220 , > unexpectedHandler = 0x82c2e9510 , > terminateHandler = 0x83041e0e0 , nextException = 0x0, > handlerCount = 0, handlerSwitchValue = 0, > actionRecord = 0x82a216508 "\003}\004", > languageSpecificData = 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\215\003\003\233\003\t\220\003Z", catchTemp = 0x0, adjustedPtr = 0x87b5aff00, unwindHeader = { > exception_class = 35100989840, exception_cleanup = 0x0, > private_1 = 34912978464, private_2 = 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 >= 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 >= 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 != &deleteException) { > auto const header1 = reinterpret_cast<__cxa_exception const *>( > reinterpret_cast(header) - 8); > if (header1->exceptionDestructor == &deleteException) { > header = header1; > } else { > auto const header2 = reinterpret_cast<__cxa_exception const *>( > reinterpret_cast(header) + 8); > if (header2->exceptionDestructor == &deleteException) { > header = 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 = 8; > #else > static const int exception_alignment_padding = 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 > Thanks for your hard work! Maybe, editors/libreoffice should adapt to the change if __UNWIND_H__ is defined in /usr/include/unwind.h, but if some others (including not-yet-ported softwares) have the same problem, compat hack on base would be better preferred. If there is a standard way to avoid this (use already-existing wrapper function?), it would be better fixing editors/libreoffice with some hints written into porter's handbook. -- Tomoaki AOKI