Bug 457712

Summary: Failed building valgrind (memcheck) for Linux powerpc32 (undefined reference to `__floatsidf') with recent gcc
Product: [Developer tools] valgrind Reporter: Christophe Leroy <christophe.leroy>
Component: memcheckAssignee: Julian Seward <jseward>
Status: REPORTED ---    
Severity: critical    
Priority: NOR    
Version First Reported In: 3.19.0   
Target Milestone: ---   
Platform: Other   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:

Description Christophe Leroy 2022-08-10 09:55:31 UTC 
Using glibc-2.35

./configure --host=ppc-linux --prefix=/usr --enable-only32bit --disable-tls

The build fails with the following errors

/opt/cldk-1.5.1rc1b1/lib/gcc/ppc-linux/11.2.0/../../../../ppc-linux/bin/ld: 
memcheck_ppc32_linux-mc_main.o: in function `gcSecVBitTable':
/home/chleroy/ldb_base/ofs/packages/valgrind-3.19.0/memcheck/mc_main.c:993: 
undefined reference to `__floatsidf'
/opt/cldk-1.5.1rc1b1/lib/gcc/ppc-linux/11.2.0/../../../../ppc-linux/bin/ld: 
/home/chleroy/ldb_base/ofs/packages/valgrind-3.19.0/memcheck/mc_main.c:998: 
undefined reference to `__floatsidf'
/opt/cldk-1.5.1rc1b1/lib/gcc/ppc-linux/11.2.0/../../../../ppc-linux/bin/ld: 
/home/chleroy/ldb_base/ofs/packages/valgrind-3.19.0/memcheck/mc_main.c:998: 
undefined reference to `__muldf3'
/opt/cldk-1.5.1rc1b1/lib/gcc/ppc-linux/11.2.0/../../../../ppc-linux/bin/ld: 
/home/chleroy/ldb_base/ofs/packages/valgrind-3.19.0/memcheck/mc_main.c:997: 
undefined reference to `__ltdf2'
/opt/cldk-1.5.1rc1b1/lib/gcc/ppc-linux/11.2.0/../../../../ppc-linux/bin/ld: 
/home/chleroy/ldb_base/ofs/packages/valgrind-3.19.0/memcheck/mc_main.c:999: 
undefined reference to `__muldf3'
/opt/cldk-1.5.1rc1b1/lib/gcc/ppc-linux/11.2.0/../../../../ppc-linux/bin/ld: 
/home/chleroy/ldb_base/ofs/packages/valgrind-3.19.0/memcheck/mc_main.c:999: 
undefined reference to `__fixdfsi'
/opt/cldk-1.5.1rc1b1/lib/gcc/ppc-linux/11.2.0/../../../../ppc-linux/bin/ld: 
/home/chleroy/ldb_base/ofs/packages/valgrind-3.19.0/memcheck/mc_main.c:1008: 
undefined reference to `__muldf3'
/opt/cldk-1.5.1rc1b1/lib/gcc/ppc-linux/11.2.0/../../../../ppc-linux/bin/ld: 
/home/chleroy/ldb_base/ofs/packages/valgrind-3.19.0/memcheck/mc_main.c:1007: 
undefined reference to `__ltdf2'
Comment 1 Christophe Leroy 2022-08-10 09:58:24 UTC 
Looking at gcc history, I found:

commit e610393ca76b204d861177a9ec542e2b4b3956cb
Author: Joseph Myers <joseph@codesourcery.com>
Date:   Thu Oct 30 17:28:30 2014 +0000

     Make soft-fp symbols into compat symbols for powerpc*-*-linux*.

     Continuing preparations for implementing
     TARGET_ATOMIC_ASSIGN_EXPAND_FENV for powerpc*-*-linux* soft-float and
     e500, this patch makes soft-fp symbols used for those targets into
     compat symbols when building with glibc >= 2.19, so that they are only
     in shared libgcc for existing binaries requiring them, not in static
     libgcc and not available for new links using shared libgcc.  Instead,
     new links will get the symbols from libc, which has exported all of
     them since 2.19.  ....


I understand that:
- libc is required to get those symbols.
- valgrind is intentionaly linked without libc but with libgcc only (from comments in coregrind/m_main.c)
Comment 2 Christophe Leroy 2022-08-10 10:00:24 UTC 
John Reiser suggested a work-around (see below). That doesn't work, I ended up pulling the entire glibc objects and got conflicts with other symbols, I gave up.

2. Possible work-around: Extract the missing functions from libc.a
   into separate *.o files:
      __floatsidf.o, __muldf3.o, __ltdf2.o, __fixdfsi.o, etc.
   Use something like these commands:
         # See if what you want really is in libc.a
      nm -gop libc.a  |  grep -E '__floatsidf|__muldf3|__ltdf2|__fixdfsi'

         # See the actual components of the libc.a archive
      ar t libc.a

         # Extract the files that you want
      ar x libc.a __floatsidf.o __muldf3.o __ltdf2.o __fixdfsi.o

   Then add those *.o filenames to the command line for 'ld'.
Comment 3 Christophe Leroy 2022-08-10 10:04:40 UTC 
I was previously using glibc 2.23 and it was working perfectly as glibc 2.23 provides those missing symbols
Comment 4 Christophe Leroy 2022-08-10 10:06:50 UTC 
I was previously using glibc 2.23 with gcc 5 and it was working perfectly as the symbols where present in libgcc.

With gcc 11 and glibc 2.35 it doesn't work anymore because the symbols are not anymore in libgcc.