Introduce lib/libgcc_eh and lib/libgcc_s for LLVM's implementation

[emaste]

Summary

Not yet connected into the build.

[emaste]

lib/libgcc_s/Makefile

13 ↗

(On Diff #21169)

div{d,s,x}c3.c contains calls to builtins such as __builtin_scalbnl, which Clang turns back into a call to scalbnl. For now I've worked around it by linking the required routines from libm, with an additional change like:

+LIBCSRCDIR=    ${SRCTOP}/lib/libc
+LIBMSRCDIR=    ${SRCTOP}/lib/msun/src
+CFLAGS+=       -I${LIBCSRCDIR}/include -I${LIBCSRCDIR}/${MACHINE_CPUARCH}
+CFLAGS+=       -I${LIBMSRCDIR}
+.PATH:         ${LIBMSRCDIR}
+SRCS+=         s_fabs.c
+SRCS+=         s_fabsf.c
+SRCS+=         s_fabsl.c
+SRCS+=         s_fmax.c
+SRCS+=         s_fmaxf.c
+SRCS+=         s_fmaxl.c
+SRCS+=         s_logb.c
+SRCS+=         s_logbf.c
+SRCS+=         s_logbl.c
+SRCS+=         s_scalbn.c
+SRCS+=         s_scalbnf.c
+SRCS+=         s_scalbnl.c

[emaste]

lib/libgcc_eh/Makefile.inc

8 ↗

(On Diff #21169)

I can't recall why this was there; will remove it.

lib/libgcc_s/Makefile

13 ↗

(On Diff #21169)

That change is now D8190

lib/libgcc_s/Version.map

1–4 ↗

(On Diff #21169)

@kib should GCC_4_3_0 inherit from GCC_4.2.0? I think probably so, but this is what gcc did.

[kib]

lib/libgcc_s/Version.map

1–4 ↗

(On Diff #21169)

I looked at libgcc_s.so from gcc 6.2. There

0x0134: Rev: 1  Flags: none  Index: 10  Cnt: 2  Name: GCC_4.3.0
0x0150: Parent 1: GCC_4.2.0

so it should be done.

Note that our rtld does not make any use of the inheritance, but for ABI compatibility inheritance should be maintained. Also there is no reason to add bugs.

[emaste]

make GCC_4_3_0 inherit from GCC_4_2_0

[emaste]

head/lib/libgcc_s/Makefile

5

Moved to /lib in rS307864

[bdrewery]

head/lib/libgcc_eh/Makefile.inc

28–30

Hm, where did this come from?

[dim]

head/lib/libgcc_eh/Makefile.inc

28–30

I think this is a hack to make the C++ source files compile, since they need C++ headers. And to make it possible to compile libgcc_eh before libc++, probably? @emaste, do you recall?

[theraven]

head/lib/libgcc_eh/Makefile.inc

14

Do we need this? I don't think we use SJLJ exceptions anywhere do we?

[dim]

head/lib/libgcc_eh/Makefile.inc

14

You're likely right, I guess this was in the list of files compiled by upstream. @emaste?

[dim]

head/lib/libgcc_eh/Makefile.inc

14

The whole Unwind-sjlj.c file is clamped between #ifdef _LIBUNWIND_BUILD_SJLJ_APIS guards, and in config.h, there is:

#if (defined(__APPLE__) && defined(__arm__)) || defined(__USING_SJLJ_EXCEPTIONS__)
#define _LIBUNWIND_BUILD_SJLJ_APIS
#endif

Obviously the Apple part doesn't apply to us, and __USING_SJLJ_EXCEPTIONS__ seems to be defined only when LangOpts.SjLjExceptions is true. It *seems* that this option is false by default, though.

[emaste]

It looks like we should be able to do away with it