Make compiler-rt's quad-math routines available to libgcc_s

[emaste]

Summary

• enable the existing quad-math compiler-rt routines also for amd64
• add them to the libgcc_s Version.map
• add version definition entries up to GCC_4.6.0

[emaste]

The initial change in the review is not complete but gets us closer and having this should produce more useful error messages from rtld.

The following symbols will still not be provided:

__eqtf2@@GCC_4.6.0
__getf2@@GCC_4.6.0
__gttf2@@GCC_4.6.0
__letf2@@GCC_4.6.0
__lttf2@@GCC_4.6.0
__netf2@@GCC_4.6.0

these are tf comparisons for =, >=, >, <=, <, !=. They are implemented in comparetf2.c, and just need to have the symbols added to the Version.map.

[emaste]

Add comparetf2 routines

[emaste]

128 bit float support did not come to GCC on FreeBSD until GCC 4.6.0.

[emaste]

This is not right: the source files are wrapped in #if defined(CRT_HAS_128BIT) && defined(CRT_LDBL_128BIT) and require that long double is 128-bit.

[emaste]

Just add new symbols to version file -- additional work is required to enable this for amd64, but this should have an effect on arm64 and riscv64.

[dim]

Do we have some sort of test case that we can use to "prove" that adding these symbols works? Like building and running a certain port?

[tijl]

Our libgcc_s needs to be ABI compatible with GCC libgcc_s so it doesn't matter which one is loaded at runtime. So, if the symbols have version GCC_3.0 in GCC libgcc_s they should have that version in our libgcc_s.

[db]

In D11482#423561, @dim wrote:

Do we have some sort of test case that we can use to "prove" that adding these symbols works? Like building and running a certain port?

Tons of them to choose from. (From today's email)

Date: Sat, 30 Mar 2019 10:54:43 +0400
From: Gleb Popov <[e-mail]>
To: "Russell L. Carter" <[e-mail]>
Cc: FreeBSD Ports ML <[e-mail]>
Subject: Re: FreeCAD 0.17 && /lib//libgcc_s.so.1

Sorry for being late to the party, but this Differential revision looks
related: https://reviews.freebsd.org/D11482

The key thing to remember here is without this update programs will not error out until they load a module referencing a libgcc_s with version definitions requiring GCC 4.6.0 e.g. late binding at runtime so there is no easy compile test.

@emaste is right with his comment July 5, 2017 (!) "this should produce more useful error messages from rtld." an interim patch could be tested to see which symbols fail to be linked and still need to be provided by our libgcc_s despite satisfying the version defition of GCC 4.6.0 .

[dim]

I made an overview of the symbols in ports gcc's libgcc_s.so.1 versions (checking gcc 5 through 8), and we're missing the following, currently:

@@ -151,4 +119,57 @@
 GCC_4.3.0 {
        __bswapdi2;
        __bswapsi2;
+       __emutls_get_address;
+       __emutls_register_common;
 } GCC_4.2.0;
+
+GCC_4.6.0 {
+       __addtf3;
+       __divtc3;
+       __divtf3;
+       __eqtf2;
+       __extenddftf2;
+       __extendsftf2;
+       __extendxftf2;
+       __fixtfdi;
+       __fixtfsi;
+       __fixtfti;
+       __fixunstfdi;
+       __fixunstfsi;
+       __fixunstfti;
+       __floatditf;
+       __floatsitf;
+       __floattitf;
+       __floatunditf;
+       __floatunsitf;
+       __floatuntitf;
+       __getf2;
+       __gttf2;
+       __letf2;
+       __lttf2;
+       __multc3;
+       __multf3;
+       __negtf2;
+       __netf2;
+       __powitf2;
+       __subtf3;
+       __trunctfdf2;
+       __trunctfsf2;
+       __trunctfxf2;
+       __unordtf2;
+} GCC_4.3.0;
+
+GCC_4.7.0 {
+       __clrsbdi2;
+       __clrsbti2;
+} GCC_4.6.0;
+
+GCC_4.8.0 {
+       __cpu_indicator_init;
+       __cpu_model;
+} GCC_4.7.0;
+
+GCC_7.0.0 {
+       __divmodti4;
+} GCC_4.8.0;

Unfortunately we don't have all of those in compiler-rt, but at least a few are missing from this review. I would add these too:

GCC_4.6.0 {
       __divtc3;
       __multc3;
} GCC_4.3.0;

GCC_4.8.0 {
       __cpu_indicator_init;
       __cpu_model;
} GCC_4.6.0;

[mikael]

I'm hitting this issue on aarch64 and it's fixed with this patch, can we get something committed? :

ld: error: undefined symbol: __subtf3 
ld: error: undefined symbol: __multf3 
ld: error: undefined symbol: __addtf3
ld: error: undefined symbol: __divtf3

[dim]

We have other issues in our libgcc_s, but I'm fine with the direction this patch is going in. It needs a few more functions still, though.

[arrowd]

What's required to get this committed?

[arrowd]

Every time I update science/dlib-cpp I stumble upon my own comment:

# uses gcc until https://reviews.freebsd.org/D11482 lands
BLASLAPACK_USE=		gcc=yes

Can this finally be committed?

[arrowd]

Every time I update science/dlib-cpp I stumble upon my own comment:

It happened again.

[mikael]

It's still a problem

[dim]

Closing this in favor of D28690.