[Bug 282705] Undefined symbols on armv7: "ld: error: undefined symbol: __truncdfsf2", "ld: error: undefined symbol: __nedf2", etc on the port graphics/oculante

From: <bugzilla-noreply_at_freebsd.org>
Date: Fri, 15 Nov 2024 18:00:57 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=282705

--- Comment #3 from Dimitry Andric <dim@FreeBSD.org> ---
Looks like the rabbit hole goes a little deeper. We already compile VFP
versions of these, via the Makefile.inc fragment:

.for file in ${SRCF}
.if ${MACHINE_CPUARCH} == "arm" && (!defined(CPUTYPE) || ${CPUTYPE:M*soft*} ==
"") \
    && exists(${CRTSRC}/${CRTARCH}/${file}vfp.S)
SRCS+=          ${file}vfp.S
. elif exists(${CRTSRC}/${CRTARCH}/${file}.S)
SRCS+=          ${file}.S
. else
SRCS+=          ${file}.c
. endif
.endfor

In contrib/llvm-project/compiler-rt/lib/builtins/arm there are:

adddf3vfp.S
addsf3vfp.S
divdf3vfp.S
divsf3vfp.S
extendsfdf2vfp.S
fixdfsivfp.S
fixsfsivfp.S
floatsidfvfp.S
floatsisfvfp.S
muldf3vfp.S
mulsf3vfp.S
subdf3vfp.S
subsf3vfp.S
truncdfsf2vfp.S

and a bunch more. However, llvm does not emit these on FreeBSD. In
contrib/llvm-project/llvm/lib/Target/ARM/ARMISelLowering.cpp there is:

ARMTargetLowering::ARMTargetLowering(const TargetMachine &TM,
                                     const ARMSubtarget &STI)
...
  if (Subtarget->isTargetMachO()) {
    // Uses VFP for Thumb libfuncs if available.
    if (Subtarget->isThumb() && Subtarget->hasVFP2Base() &&
        Subtarget->hasARMOps() && !Subtarget->useSoftFloat()) {
      static const struct {
        const RTLIB::Libcall Op;
        const char * const Name;
        const ISD::CondCode Cond;
      } LibraryCalls[] = {
        // Single-precision floating-point arithmetic.
        { RTLIB::ADD_F32, "__addsf3vfp", ISD::SETCC_INVALID },
        { RTLIB::SUB_F32, "__subsf3vfp", ISD::SETCC_INVALID },
        { RTLIB::MUL_F32, "__mulsf3vfp", ISD::SETCC_INVALID },
        { RTLIB::DIV_F32, "__divsf3vfp", ISD::SETCC_INVALID },
...

I am unsure whether the VFP routines are ABI compatible with the non-VFP ones.
If they are, we could alias them somehow. If they are not, we should stop
compiling the VFP versions, and compile the regular versions.

-- 
You are receiving this mail because:
You are the assignee for the bug.