Page MenuHomeFreeBSD

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

Authored by emaste on Oct 7 2016, 9:09 PM.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

emaste updated this revision to Diff 21169.Oct 7 2016, 9:09 PM
emaste retitled this revision from to Introduce lib/libgcc_eh and lib/libgcc_s for LLVM's implementation.
emaste updated this object.
emaste edited the test plan for this revision. (Show Details)
emaste added reviewers: ed, theraven, dim.
emaste added a subscriber: bapt.
emaste added inline comments.Oct 7 2016, 9:15 PM
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 added a subscriber: kib.Oct 8 2016, 12:04 AM
emaste added inline comments.
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 added inline comments.Oct 8 2016, 10:13 AM
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 updated this revision to Diff 21182.Oct 8 2016, 4:36 PM

make GCC_4_3_0 inherit from GCC_4_2_0

emaste added a subscriber: jhb.Oct 13 2016, 6:05 PM
ed accepted this revision.Oct 13 2016, 6:36 PM
ed edited edge metadata.
This revision is now accepted and ready to land.Oct 13 2016, 6:36 PM
This revision was automatically updated to reflect the committed changes.
emaste added inline comments.Oct 24 2016, 5:02 PM
head/lib/libgcc_s/Makefile
5

Moved to /lib in rS307864

bdrewery added inline comments.
head/lib/libgcc_eh/Makefile.inc
28–30

Hm, where did this come from?

dim added inline comments.Oct 30 2017, 10:19 PM
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 added inline comments.May 5 2020, 8:15 AM
head/lib/libgcc_eh/Makefile.inc
14

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

dim added inline comments.May 5 2020, 8:30 AM
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 added inline comments.May 5 2020, 12:10 PM
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.

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