Date: Sun, 7 Apr 2019 23:57:12 -0700 From: Mark Millard <marklmi@yahoo.com> To: Gerald Pfeifer <gerald@pfeifer.com> Cc: =?utf-8?Q?T=C4=B3l_Coosemans?= <tijl@FreeBSD.org>, Andreas Tobler <andreast@FreeBSD.org>, freebsd-toolchain@freebsd.org, Dima Pasechnik <dimpase+freebsd@gmail.com>, Steve Kargl <sgk@troutmask.apl.washington.edu>, freebsd-ports@freebsd.org, Dave Horsfall <dave@horsfall.org> Subject: Re: libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1) Message-ID: <BF5BA018-F0F5-4BAF-965E-6AAECA4D08AE@yahoo.com> In-Reply-To: <alpine.LSU.2.21.1904081314010.3629@anthias.pfeifer.com> References: <a2102b4e-7d7a-7d5b-2ba1-b9a14f8574f6@pinyon.org> <f6a45ec9-7ae4-d9ba-f71c-f2ef8c235039@grosbein.net> <416689e6-37f9-17ec-54d8-0d224c26f30f@pinyon.org> <20190217151604.GB68620@night.db.net> <20190221180515.39c79ce6@kalimero.tijl.coosemans.org> <092b17f0-6fbf-662e-1061-403442248abd@pinyon.org> <20190222140407.2145c11e@kalimero.tijl.coosemans.org> <alpine.BSF.2.21.9999.1902230913380.84718@aneurin.horsfall.org> <20190223000620.GA12700@troutmask.apl.washington.edu> <CAAWYfq20PgO9RoaN2esyqf-dc2xyqfmkLVaSe8yrx-X4E1s=ZQ@mail.gmail.com> <20190223183117.GA65065@night.db.net> <20190224142150.685debe4@kalimero.tijl.coosemans.org> <alpine.LSU.2.21.1902271446270.4073@anthias.pfeifer.com> <alpine.LSU.2.21.1904081314010.3629@anthias.pfeifer.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > What's your take, Andreas, Tijl (your patch essentially with a bit > of an updated description), and toolchain? >=20 > Gerald >=20 > On Wed, 27 Feb 2019, Gerald Pfeifer wrote: >> Hi Tijl, hi everyone,=20 >>=20 >> and let me add Andreas who has been helping on the GCC side (both=20 >> ports, viz. his work on arm and powerpc, and upstream) and = toolchain@! > : >> On Sun, 24 Feb 2019, T=C4=B3l 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. >>>=20 >>> 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. >>=20 >> 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=20= >> consideration for our ports collection, initially for lang/gcc8 given=20= >> that this is the default in the ports collection. >>=20 >>=20 >> (The lang/gcc* ports actually do carry local patches, e.g. for arm or=20= >> powerpc or -fuse-ld=3Dlld, but you are right that I usually try to = get=20 >> things upstream first, fixing things upstream myself when I can, or=20= >> asking for help. The problem in this specific case was/is that I'm=20 >> quite not enough into this area so cannot really assess and clearly >> stalling over that was not good.) >>=20 >>=20 >> Find patch-gfortran-libgcc attached which should simply plug into=20 >> lang/gcc8/files and lang/gcc8-devel/files. >>=20 >> Feedback very welcome! >>=20 >=20 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=3D contexts: For contexts using WITHOUT_LLVM_LIBUNWIND=3D 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=3D . John Baldwin and others have expressed wanting to jump to WITH_LLLVM_LIBUNWIND=3D 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=3D 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=3D has https://reviews.llvm.org/D59694 by Leandro Lupori in process for powerpc64 ( for using WITHOUT_LIB32=3D ). It should allow use of WITH_LLVM_LIBUNWIND=3D WITHOUT_LIB32=3D . [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=3D41050 . (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=3D 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=3D26844 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=3D still useless last I checked. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BF5BA018-F0F5-4BAF-965E-6AAECA4D08AE>