Wind River Support Network

HomeDefectsLIN7-5078
Fixed

LIN7-5078 : t2xxx, valgrind error "disInstr(ppc): unhandled instruction"

Created: Nov 3, 2015    Updated: Sep 8, 2018
Resolved Date: Feb 18, 2016
Found In Version: 7.0.0.10
Fix Version: 7.0.0.13
Severity: Severe
Applicable for: Wind River Linux 7
Component/s: Userspace

Description

Customer use WRlinux6 fsl-t2xxx BSP for their project.
They run valgrind on their t2080 board, get the following error:
-------------------------------
root@mcp1800:~# valgrind --tool=memcheck ./aa
==812== Memcheck, a memory error detector
==812== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==812== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==812== Command: ./aa
==812==
disInstr(ppc): unhandled instruction: 0xE8040000
primary 58(0x3A), secondary 0(0x0)
==812== valgrind: Unrecognised instruction at address 0xffcc404.
==812== at 0xFFCC404: memcpy (memcpy.S:92)
==812== by 0xFFB2CFF: _dl_start_final (rtld.c:292)
==812== by 0xFFC8B17: _start (dl-start.S:38)
==812== Your program just tried to execute an instruction that Valgrind
==812== did not recognise. There are two possible reasons for this.
==812== 1. Your program has a bug and erroneously jumped to a non-code
==812== location. If you are running Memcheck and you just saw a
==812== warning about a bad jump, it's probably your program's fault.
==812== 2. The instruction is legitimate but Valgrind doesn't handle it,
==812== i.e. it's Valgrind's fault. If you think this is the case or
==812== you are not sure, please let us know and we'll try to fix it.
==812== Either way, Valgrind will now raise a SIGILL signal which will
==812== probably kill your program.
==812==
==812== Process terminating with default action of signal 4 (SIGILL)
==812== Illegal opcode at address 0xFFCC404
==812== at 0xFFCC404: memcpy (memcpy.S:92)
==812== by 0xFFB2CFF: _dl_start_final (rtld.c:292)
==812== by 0xFFC8B17: _start (dl-start.S:38)
==812==
==812== HEAP SUMMARY:
==812== in use at exit: 0 bytes in 0 blocks
==812== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==812==
==812== All heap blocks were freed -- no leaks are possible
==812==
==812== For counts of detected and suppressed errors, rerun with: -v
==812== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction 
------------------------------------

I can reproduce this on our vlm t2080 board, with wrlinux6 RCPL 23 project.

Workaround

Please install the attached valgrind which has been patched to handle Freescale-optimized glibc.

Steps to Reproduce

1. project configure as:
/opt/WRLX6/wrlinux-6/wrlinux/configure --enable-board=fsl-t2xxx --enable-kernel=standard --enable-rootfs=glibc_std+debug --enable-jobs=8 --enable-parallel-pkgbuilds=8 --enable-reconfig --enable-rm-oldimgs=yes --with-rcpl-version=0023

2. use the exported SDK to compile a simple test program
 powerpc-wrs-linux-gcc -m32 -mhard-float -mcpu=e6500 --sysroot=/sdk-t2xxx/sysroots/ppce6500-wrs-linux -g -o /valgrind-test/aa /valgrind-test/aa.c

the aa.c is a simple test program:
-----------------
#include <stdio.h>
#include <stdlib.h>

int main()

{

    int a = 3;



    return a;

}
-----------------


3. run valgrind on target
------------------------
root@fsl_t2080rdb:~# valgrind --tool=memcheck ./aa 
==1333== Memcheck, a memory error detector
==1333== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==1333== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==1333== Command: ./aa
==1333== 
disInstr(ppc): unhandled instruction: 0xE8040000
                 primary 58(0x3A), secondary 0(0x0)
==1333== valgrind: Unrecognised instruction at address 0xffdc404.
==1333==    at 0xFFDC404: memcpy (memcpy.S:92)
==1333==    by 0xFFC2CFF: _dl_start_final (rtld.c:292)
==1333==    by 0xFFD8B17: _start (dl-start.S:38)
==1333== Your program just tried to execute an instruction that Valgrind
==1333== did not recognise.  There are two possible reasons for this.
==1333== 1. Your program has a bug and erroneously jumped to a non-code
==1333==    location.  If you are running Memcheck and you just saw a
==1333==    warning about a bad jump, it's probably your program's fault.
==1333== 2. The instruction is legitimate but Valgrind doesn't handle it,
==1333==    i.e. it's Valgrind's fault.  If you think this is the case or
==1333==    you are not sure, please let us know and we'll try to fix it.
==1333== Either way, Valgrind will now raise a SIGILL signal which will
==1333== probably kill your program.
==1333== 
==1333== Process terminating with default action of signal 4 (SIGILL)
==1333==  Illegal opcode at address 0xFFDC404
==1333==    at 0xFFDC404: memcpy (memcpy.S:92)
==1333==    by 0xFFC2CFF: _dl_start_final (rtld.c:292)
==1333==    by 0xFFD8B17: _start (dl-start.S:38)
==1333== 
==1333== HEAP SUMMARY:
==1333==     in use at exit: 0 bytes in 0 blocks
==1333==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1333== 
==1333== All heap blocks were freed -- no leaks are possible
==1333== 
==1333== For counts of detected and suppressed errors, rerun with: -v
==1333== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction
-----------------------

Other Downloads


Live chat
Online