PowerPC undefined symbol _restgpr_30_x

I'm trying to use Valgrind on an embedded PowerPC system but I'm
getting the following errors:

./testprog: symbol lookup error:
/usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so: undefined
symbol: _restgpr_30_x
disInstr(ppc): unhandled instruction: 0x0
                 primary 0(0x0), secondary 0(0x0)
==466== valgrind: Unrecognised instruction at address 0xffefa74.
==466==    at 0xFFEFA74: ??? (in
/usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)

The target setup is:
CPU: MPC8280 (PowerPC 603e core)
Linux Kernel 4.9.59
gcc 6.3.0
glibc 2.25
valgrind 3.15.0
The toolchain was generated using crosstool-NG 1.23 with a target of
"powerpc-generic-linux-gnu".

Test program is:
int main (int argc, char **argv) { return argc; }

It was compiled with:
powerpc-generic-linux-gnu-gcc -o testprog testprog.c

Valgrind was compiled like this:
./configure --host=powerpc-generic-linux-gnu
make

The full program output is as follows:

# valgrind -v ./testprog
==466== Memcheck, a memory error detector
==466== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==466== Using Valgrind-3.15.0-608cb11914-20190413 and LibVEX; rerun
with -h for copyright info
==466== Command: ./testprog
==466==
--466-- Valgrind options:
--466--    -v
--466-- Contents of /proc/version:
--466--   Linux version 4.9.59 (build@engdev) (gcc version 6.3.0
(crosstool-NG crosstool-ng-1.23.0) ) #0 PREEMPT Mon Mar 9 10:36:51 EDT
2020
--466--
--466-- Arch and hwcaps: PPC32, BigEndian, ppc32-int-flt-GX
--466-- Page sizes: currently 4096, max supported 65536
--466-- Valgrind library directory: /usr/local/lib/valgrind
--466-- Reading syms from /lib/ld-2.25.so
--466-- Reading syms from /tmp/testprog
--466-- Reading syms from /usr/local/lib/valgrind/memcheck-ppc32-linux
--466--    object doesn't have a dynamic symbol table
--466-- Scheduler: using generic scheduler lock implementation.
--466-- Reading suppressions file: /usr/local/lib/valgrind/default.supp
==466== embedded gdbserver: reading from
/tmp/vgdb-pipe-from-vgdb-to-466-by-root-on-???
==466== embedded gdbserver: writing to
/tmp/vgdb-pipe-to-vgdb-from-466-by-root-on-???
==466== embedded gdbserver: shared mem
/tmp/vgdb-pipe-shared-mem-vgdb-466-by-root-on-???
==466==
==466== TO CONTROL THIS PROCESS USING vgdb (which you probably
==466== don't want to do, unless you know exactly what you're doing,
==466== or are doing some strange experiment):
==466==   /usr/local/lib/valgrind/../../bin/vgdb --pid=466 ...command...
==466==
==466== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==466==   /path/to/gdb ./testprog
==466== and then give GDB the following command
==466==   target remote | /usr/local/lib/valgrind/../../bin/vgdb --pid=466
==466== --pid is optional if only one valgrind process is running
==466==
--466-- REDIR: 0x401b250 (ld.so.1:strcmp) redirected to 0x58116d7c
(vgPlain_ppc32_linux_REDIR_FOR_strcmp)
--466-- REDIR: 0x401b3b4 (ld.so.1:strlen) redirected to 0x58116d54
(vgPlain_ppc32_linux_REDIR_FOR_strlen)
--466-- REDIR: 0x401b174 (ld.so.1:index) redirected to 0x58116df0
(vgPlain_ppc32_linux_REDIR_FOR_strchr)
--466-- Reading syms from /usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so
--466-- Reading syms from
/usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so
--466-- REDIR: 0x401bec8 (ld.so.1:memcpy) redirected to 0xffba7e8 (memcpy)
--466-- REDIR: 0x401b820 (ld.so.1:bcmp) redirected to 0xffbb8c4 (bcmp)
--466-- Reading syms from /lib/libc-2.25.so
./testprog: symbol lookup error:
/usr/local/lib/valgrind/vgpreload_memcheck-ppc32-linux.so: undefined
symbol: _restgpr_30_x
disInstr(ppc): unhandled instruction: 0x0
                 primary 0(0x0), secondary 0(0x0)
==466== valgrind: Unrecognised instruction at address 0xffefa74.
==466==    at 0xFFEFA74: ??? (in
/usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)
==466==    by 0x404082F: ??? (in /lib/ld-2.25.so)
==466==    by 0x4018D27: _dl_signal_error (dl-error-skeleton.c:134)
==466==    by 0x4018E67: _dl_signal_cerror (dl-error-skeleton.c:166)
==466==    by 0x400AECF: _dl_lookup_symbol_x (dl-lookup.c:874)
==466==    by 0x400C977: elf_machine_rela (dl-machine.h:315)
==466==    by 0x400C977: elf_dynamic_do_Rela (do-rel.h:170)
==466==    by 0x400C977: _dl_relocate_object (dl-reloc.c:259)
==466==    by 0x4004923: dl_main (rtld.c:2051)
==466==    by 0x4017B73: _dl_sysdep_start (dl-sysdep.c:253)
==466==    by 0x4005A3F: _dl_start_final (rtld.c:305)
==466==    by 0x4005DD3: _dl_start (rtld.c:413)
==466==    by 0x401997B: _start (dl-start.S:38)
==466== Your program just tried to execute an instruction that Valgrind
==466== did not recognise.  There are two possible reasons for this.
==466== 1. Your program has a bug and erroneously jumped to a non-code
==466==    location.  If you are running Memcheck and you just saw a
==466==    warning about a bad jump, it's probably your program's fault.
==466== 2. The instruction is legitimate but Valgrind doesn't handle it,
==466==    i.e. it's Valgrind's fault.  If you think this is the case or
==466==    you are not sure, please let us know and we'll try to fix it.
==466== Either way, Valgrind will now raise a SIGILL signal which will
==466== probably kill your program.
==466==
==466== Process terminating with default action of signal 4 (SIGILL):
dumping core
==466==  Illegal opcode at address 0xFFEFA74
==466==    at 0xFFEFA74: ??? (in
/usr/local/lib/valgrind/vgpreload_core-ppc32-linux.so)
==466==    by 0x404082F: ??? (in /lib/ld-2.25.so)
==466==    by 0x4018D27: _dl_signal_error (dl-error-skeleton.c:134)
==466==    by 0x4018E67: _dl_signal_cerror (dl-error-skeleton.c:166)
==466==    by 0x400AECF: _dl_lookup_symbol_x (dl-lookup.c:874)
==466==    by 0x400C977: elf_machine_rela (dl-machine.h:315)
==466==    by 0x400C977: elf_dynamic_do_Rela (do-rel.h:170)
==466==    by 0x400C977: _dl_relocate_object (dl-reloc.c:259)
==466==    by 0x4004923: dl_main (rtld.c:2051)
==466==    by 0x4017B73: _dl_sysdep_start (dl-sysdep.c:253)
==466==    by 0x4005A3F: _dl_start_final (rtld.c:305)
==466==    by 0x4005DD3: _dl_start (rtld.c:413)
==466==    by 0x401997B: _start (dl-start.S:38)
==466==
==466== HEAP SUMMARY:
==466==     in use at exit: 0 bytes in 0 blocks
==466==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==466==
==466== All heap blocks were freed -- no leaks are possible
==466==
==466== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)


What am I doing wrong? Could there be a problem with my toolchain?