On 2019-Apr-7, at 22:16, Gerald Pfeifer <gerald at pfeifer.com> wrote:
> Hmm, I received zero feedback on this proposal, when it appeared > important for a number of users. > > What's your take, Andreas, Tijl (your patch essentially with a bit > of an updated description), and toolchain? > > Gerald > > On Wed, 27 Feb 2019, Gerald Pfeifer wrote: >> Hi Tijl, hi everyone, >> >> and let me add Andreas who has been helping on the GCC side (both >> ports, viz. his work on arm and powerpc, and upstream) and toolchain@! > : >> On Sun, 24 Feb 2019, Tijl Coosemans wrote: >>> GCC_4.3.0 instead of GCC_3.3.0. The gcc commit that changed this >>> doesn't explain why this was done, but we'll have to make the same >>> change in FreeBSD ARM libgcc_s to be ABI compatible (since _Unwind* is >>> part of the ABI). This isn't a blocker for the patch. >>> >>> I emailed the patch to gerald on 2017-02-21. He responded in the usual >>> way that he prefers patches submitted upstream and because I thought the >>> patch would not be accepted upstream he proposed an alternative solution >>> where gcc would always add -rpath on FreeBSD so you didn't have to >>> specify it on the command line. I responded this wouldn't fix the case >>> where clang was used as a linker (e.g. to combine fortran and c++ code >>> in one program) and that the FAQ on the gcc website said it was a bad >>> idea for other reasons. I also said upstream might accept my patch if >>> it was a configure option but that the gcc configure scripts are >>> complicated and I didn't know where to add it exactly. Then silence. >> >> To move this forward, let me include an updated version of the patch >> Tijl shared on 2017-02-21 (which still was in my inbox/todo list) for >> consideration for our ports collection, initially for lang/gcc8 given >> that this is the default in the ports collection. >> >> >> (The lang/gcc* ports actually do carry local patches, e.g. for arm or >> powerpc or -fuse-ld=lld, but you are right that I usually try to get >> things upstream first, fixing things upstream myself when I can, or >> asking for help. The problem in this specific case was/is that I'm >> quite not enough into this area so cannot really assess and clearly >> stalling over that was not good.) >> >> >> Find patch-gfortran-libgcc attached which should simply plug into >> lang/gcc8/files and lang/gcc8-devel/files. >> >> Feedback very welcome! >> > I'm not sure the following will be considered important for the above, but I'll note it in case. A problem of sorts for WITHOUT_LLVM_LIBUNWIND= contexts: For contexts using WITHOUT_LLVM_LIBUNWIND= that might not use gcc 4.2.1 , use of the system libgcc_s is problematical: the old libunwind code does not correctly (not completely) implement DW_CFA_remember_state and DW_CFA_restore_state . It happens that g++ 4.2.1 (mostly?) avoids generating code that needs them. But modern clang++ and g++ do generate code frequently that needs DW_CFA_remember_state and DW_CFA_restore_state to work. Because I experiment with clang/clang++ and devel/powerpc64-gcc for buildworld buildkernel for powerpc64 (and powerpc), I use a patched libgcc_s when I try WITHOUT_LLVM_LIBUNWIND= . John Baldwin and others have expressed wanting to jump to WITH_LLLVM_LIBUNWIND= use (not with gcc 4.2.1), without fixing the old code first. Out of the mess described later: powerpc64 and powerpc are not yet ready for general, non-experimental WITH_LLVM_LIBUNWIND= use. I do not know the status of any potential blocking issues for switching for other architectures officially still using gcc/g++ 4.2.1 . powerpc64 and powerpc details: WITH_LLVM_LIBUNWIND= has https://reviews.llvm.org/D59694 by Leandro Lupori in process for powerpc64 ( for using WITHOUT_LIB32= ). It should allow use of WITH_LLVM_LIBUNWIND= WITHOUT_LIB32= . [As stands llvm's libunwind mungs up handling r2 (the powerpc64 TOC register).] https://reviews.llvm.org/D59694 is associated with https://bugs.llvm.org//show_bug.cgi?id=41050 . (That last has a messy comment history from my figuring out information as I went.) Handling thrown C++ exceptions need not be the only issue blocking system-clang use for one or both powerpc family branches. For 32-bit powerpc it is known to not be the only issue. powerpc64 via clang/clang++ ends up with a WITH_LIB32= issue from some of the 32-bit powerpc related issues. But even without that, clang/clang++ for buildworld does not support the implicit Dwarf-like EH generation that the old code requires for its use of __builtin_eh_return . This leads to any thrown c++ exdpetion crashing the program invovled. There is https://bugs.llvm.org//show_bug.cgi?id=26844 for this issue. (It has been around a while.) devel/powerpc644-gcc does the right thing for this when used for buildworld --but has its own issues that make WITH_LIB32= still useless last I checked. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) _______________________________________________ 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"
