libgcc_s.so.1, Fortran, and the world (was: FreeCAD 0.17 && /lib//libgcc_s.so.1)

[Mark Millard]

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)