How to get devel/powerpc-gcc based WITH_LIBCPLUSPLUS= buildworld to have some throwing of C++ exceptions work (patch)
I now have a patch that gets some basic C++ exception throwing going for WITH_LIBCPLUSPLUS= use when building via devel/powerpc64-gcc . But the overall mechanism seems to mess up the handling of powerpc64's "red zone" style of stack processing in various cases. I've had recent list submittals reporting that buildworld using WITH_LIBCPLUSPLUS= based on devel/powerpc64-gcc would get stuck looping in _Unwind_RaiseException. This prevented use of devel/gdb --which makes extensive use of throwing C++ exceptions in normal operation. Well, I now have a patch that avoids the problem in libcxxrt's throw_exception itself that made all throws get stuck --and so allows some C++ exceptions to be thrown. See below. (I'm not sure leading spaces will all be preserved.) Most of text is commentary, not code. # svnlite diff /usr/src/contrib/libcxxrt/ Index: /usr/src/contrib/libcxxrt/exception.cc === --- /usr/src/contrib/libcxxrt/exception.cc (revision 339076) +++ /usr/src/contrib/libcxxrt/exception.cc (working copy) @@ -772,10 +772,71 @@ info->globals.uncaughtExceptions++; _Unwind_Reason_Code err = _Unwind_RaiseException(>unwindHeader); +#if !defined(__powerpc64__) && !defined(__ppc64__) // The _Unwind_RaiseException() function should not return, it should // unwind the stack past this function. If it does return, then something // has gone wrong. report_failure(err, ex); +#else +// NOTE: Only tested for devel/powerpc64-gcc based buildworld +// because clang still silently ignores +// __builtin_eh_return(offset,handler) for powerpc64 +// (and powerpc), thus not generating correct output. +// +// NOTE: I've no clue if other archtiectures might have +// analogous issues to powerpc64. I'm not sure +// about powerpc because of it still being stuck +// at gcc 4.2.1 . (clang problems and no devel/powerpc-gcc .) +// +// The above/normal code produced the following sort of structure +// for throw_exception. r1 is the stack pointer, note its adjustments +// via stdu r1,-128(r1) and via addi r1,r1,128 . +// +// :mflrr0 +// :std r31,-8(r1) +// :mr r31,r3 +// : std r0,16(r1) +// : stdur1,-128(r1) +// . . . +// : bl <0018.plt_call._Unwind_RaiseException@@GCC_3.0> +// : ld r2,40(r1) +// : addir1,r1,128 +// : mr r4,r31 +// : ld r0,16(r1) +// : ld r31,-8(r1) +// : mtlrr0 +// : b +// +// The loop in __Unwind_RaiseException had its "fs" +// used with uw_frame_state_for and uw_update_context get +// stuck with the pc field having the address for +// throw_exception+152 (just after the stack adjustment +// addi r1,r1,128). Effectively, throw_exception unwinds +// its stack use before calling report_failure in a +// way that throw_exception is no longer on the stack. +// The exception unwinding logic did not handle this +// correctly and got stuck looping. +// +// The below avoids having any such stack adjustment here +// by avoiding the report_failure call and directly doing +// what case _URC_END_OF_STACK in report_failure does for +// its first couple of lines. (It is also the kind of +// thing that src/contrib/libstdc++/libsupc++/eh_throw.cc +// has in its __cxxabiv1::__cxa_throw after the +// _Unwind_RaiseException call.) +// +// Another option could be to turn report_failure into +// a macro so that no subroutine call could be involved. +// That should avoid the early stack pointer kadjsutment. +// +// Also: For the other archtiectures that I looked at, no +// such stack adjsutments were involved in the code +// generated (or the matching dwarfdump output). +// But I did not look at many. + + __cxa_begin_catch (&(ex->unwindHeader)); + std::terminate(); +#endif } However, code such as the following from devel/kyua leads to other examples of _Unwind_RaiseException looping without making progress. Note the stdu r1,-368(r1) and the addi r1,r1,368 stack pointer adjustments and their timing relative to stack usage (the "red zone" style used for FreeBSD's powerpc64 ABI): (gdb) x/64i 0x100a8528-88 0x100a84d0 : mflrr0 0x100a84d4 :std r30,-16(r1) 0x100a84d8 :std r31,-8(r1) 0x100a84dc : std r29,-24(r1) 0x100a84e0 : mr r31,r4 0x100a84e4 : std r0,16(r1) 0x100a84e8 : stdu r1,-368(r1) 0x100a84ec : mr r30,r3 0x100a84f0 : bl 0x100abab0 0x100a84f4 : nop 0x100a84f8 : clrlwi r4,r31,16 0x100a84fc : bl 0x10009fc0 <00af.plt_call.mkdir@@FBSD_1.0> 0x100a8500 : ld r2,40(r1) 0x100a8504 : cmpwi cr7,r3,-1 0x100a8508 : beq cr7,0x100a8528 0x100a850c : addi r1,r1,368 0x100a8510 : ld r0,16(r1)
[Bug 215039] head -r339076 TARGET_ARCH=powerpc64 clang 6.0.1 based buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts and rejects .S file contents
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215039 Mark Millard changed: What|Removed |Added Summary|head -r309179 |head -r339076 |TARGET_ARCH=powerpc64 clang |TARGET_ARCH=powerpc64 clang |3.9.0 based buildworld on |6.0.1 based buildworld on |powerpc64 using |powerpc64 using |WITH_LLVM_LIBUNWIND= fails |WITH_LLVM_LIBUNWIND= fails |to build: asserts and |to build: asserts and |rejects .S file contents|rejects .S file contents -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
[Bug 215039] head -r309179 TARGET_ARCH=powerpc64 clang 3.9.0 based buildworld on powerpc64 using WITH_LLVM_LIBUNWIND= fails to build: asserts and rejects .S file contents
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215039 --- Comment #3 from Mark Millard --- Note: I recently posted to a list that the problems still exist as of head -r339076 . This was in reply to a suggestion to try it. But the particular experiment was adding WITH_LLVM_LIBUNWIND= to a src.conf type of file for using devel/powerpc64-gcc to do the build (on a powerpc64). [clang is still not up to it.] For example, UnwindRegistersRestore.S did not get the C-preprocessor handling that it is designed for and the __ppc__ assembler notation still has "register designations are a Darwinism" status. The ";" comment notation also might be a Darwinism as far as I know. WITH_LLVM_LIBUNWIND= is not yet an option for powerpc64 and the like. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
Re: GPL requirements vs. "some of which are compiled with GCC" terms in special exceptions?
[WITH_LLVM_LIBUNWIND= is still broken for powerpc64 (and likely powerpc).] On 2018-Oct-13, at 7:54 PM, Mark Millard wrote: > On 2018-Oct-13, at 7:40 PM, Mark Millard wrote: > >> On 2018-Oct-13, at 10:15 AM, David Chisnall wrote: >> >>> This is a known problem with the GCC runtime libraries. GCC 4.3 and later >>> have a much better exemption (which talks about any eligible compilation >>> process, rather than being compiled with GCC), but those are GPLv3 and so >>> unacceptable for FreeBSD. >> >> I see. Good to know. > > Hmm. As of head -r339076 the src.conf man page says: > > WITHOUT_LLVM_LIBUNWIND > Set to use GCC's stack unwinder (instead of LLVM's libunwind). > > This is a default setting on arm/arm, arm/armv6, arm/armv7, > powerpc/powerpc, powerpc/powerpc64, powerpc/powerpcspe and > sparc64/sparc64. > > I believe arm/armv7, arm/armv6, and arm/arm are using clang for such > vintages: > > WITH_CLANG_BOOTSTRAP > Set to build the Clang C/C++ compiler during the bootstrap phase > of the build. > > This is a default setting on amd64/amd64, arm/arm, arm/armv6, > arm/armv7, arm64/aarch64 and i386/i386. > > > But may be the man page is just out of date for WITHOUT_LLVM_LIBUNWIND ? > >>> I don’t believe that we are using any of those files on platforms where >>> clang is the default system compiler. LLVM’s libUnwind should be able to >>> handle PowerPC on Linux, so it’s worth checking if this is the case on >>> FreeBSD. >> >> Last I tried llvm's libunwind for powerpc64 was back in 2016-Dec/2017-Jan. >> See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=215039 . There was also >> the llvm submittal 31590. >> >> I might try it again at some point. But clang and llvm have other issues for >> use for buildworld buildkernel as well as I understand. (But I'm doing some >> new experiments these days.) >> >> I've no clue if llvm's libunwind is intended to be compliant with the >> powerpc64 and powerpc ABIs that FreeBSD bases itself on for the powerpc >> family. >> On 13 Oct 2018, at 18:12, Mark Millard via freebsd-toolchain wrote: While investigating powerpc64 C++ exception handling for builds under devel/powerpc64-gcc I ran into the following in /usr/src/contrib/gcc/unwind-dw2-fde-glibc.c : /* As a special exception, if you link this library with other files, some of which are compiled with GCC, to produce an executable, this library does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License. */ So in contexts were clang/llvm is used to exclusion . . . are any such files in use? (I happen to be using devel/powerpc64-gcc at the moment.) For me this has no real implications: I do not distribute my experiments. But I was surprised by what I read. Looking I find: # grep -r "some of which are compiled with GCC" /usr/src/* | more /usr/src/contrib/gcc/config/i386/gthr-win32.c: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/crtend.asm: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/fde-glibc.c: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/crtbegin.asm: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/lib1funcs.asm: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/crtfastmath.c: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/ia64/unwind-ia64.c: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/mips/mips16.S: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/config/vxlib.c: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/libgcc2.h: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/gthr-posix95.h: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/gthr-posix.h: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/gthr-posix.c: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/gbl-ctors.h: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/gthr-gnat.c: some of which are compiled with GCC, to produce an executable, /usr/src/contrib/gcc/gthr-rtems.h:
Re: xmlcharent-0.3_2 and iso8879-1986_3 package reinstalls: "pkg: POST-INSTALL script failed"? vs. @xmlcatmgr and Keywords/xmlcatmgr.ucl
Am 11.10.18 um 17:39 schrieb Mark Millard via freebsd-toolchain: > In updating a powerpc64 context after a poudriere-devel bulk run, I > got the following from pkg upgrade . . . > > Installed packages to be REINSTALLED: xmlcharent-0.3_2 (ABI changed: > 'freebsd:12:powerpc:64' -> 'freebsd:12:*') > . . . > iso8879-1986_3 (ABI changed: 'freebsd:12:powerpc:64' -> 'freebsd:12:*') > . . . > > [127/181] Extracting iso8879-1986_3: 100% > xmlcatmgr: entry already exists for `/usr/local/share/sgml/iso8879/catalog' > of type `CATALOG' > pkg: POST-INSTALL script failed > > . . . > > [138/181] Extracting xmlcharent-0.3_2: 100% > xmlcatmgr: entry already exists for `/usr/local/share/xml/xmlcharent/catalog' > of type `CATALOG' > xmlcatmgr: entry already exists for > `/usr/local/share/xml/xmlcharent/catalog.xml' of type `nextCatalog' > pkg: POST-INSTALL script failed > > The context is a personal head-based -r339076 buildworld > buildkernel (it was cross built) and ports being updated > based on -r480180 . > > Is there anything that I should do because of the messages? Mark, no need, it seems the failure is harmless on upgrades. It appears to be a bug in the @xmlchatmgr lines for pkg-plist files, and I have seen these xmlcatmgr complaints you are showing for ages on all ports that install SGML or XML catalogs when they are upgraded, if you manually deinstall (pkg delete -f) and reinstall these ports, they do not appear. I question the ports/Keywords/xmlcatmgr.ucl and wonder if what is currently labelled a post-deinstall action should become a pre-deinstall action - and unfortunately, I have not found documentation on this so cannot propose a patch. Possibly we also need a pre-/post-upgrade action pair to solve this. Baptiste, any insights? ___ freebsd-toolchain@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-toolchain To unsubscribe, send any mail to "freebsd-toolchain-unsubscr...@freebsd.org"
