Those happen, don't take it personally. They used to be real common
in ARM. Sounds like you hit a code that's not covered. Not that I'm
one that can add it.
See the "==466== Your program just tried to execute an instruction that Valgrind
==466== did not recognise." section of the error message. OTOH
somewhere it looks like it jumped to a null.
On 3/22/20, MP <mxm...@gmail.com> wrote:
> 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?
>
>
> _______________________________________________
> Valgrind-users mailing list
> Valgrind-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
--
-------------
No, I won't call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach Impeach Impeach Impeach Impeach Impeach Impeach Impeach
_______________________________________________
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
