Created attachment 83020 [details]
Add support cavium octeon specific Load Indexed instructions

******************  PRE-REQUISITES   *****************

----Testing Enviroment specification:-----
																			
SDK             3.0 with new tool chain																		
Tool-chain	tool-121004																		
gcc version	4.7																		
glibc version	2.11																		
kernel version	3.4.27-rt37-Cavium-Octeon																		
cpu info	Cavium Octeon II V0.1																		
MotherBoard	OCTEON_CN63XX																		

valgrind 3.9.0 	r13667 release 13667
command to checkout: svn co -r 13667 svn://svn.valgrind.org/valgrind/trunk valgrind

******************  Applying patch   *****************

copy patch file to valgrind folder and following command should be run to apply patch.
run patch -p1 -i valgrind_3.9_r13667_22_oct_2013.patch 

******************  Files patched   *****************
patch file none/tests/mips64/Makefile.am
patch file tests/mips_features.c
patch file VEX/priv/guest_mips_toIR.c

********  Instructions added (Cavium specific) ******
- lbx
- lhux
- lwux
- ldx

Created attachment 83023 [details]
Test Cases

Created attachment 83025 [details]
Output File

Couple of general remarks:

- Please avoid attaching archives, rather attach plain text patches.
- Rebase your patch to the ToT

Have you tested your patch on both LE and BE MIPS64? If not, can you please do it and add if anything is missing for it?

> + cvm_lx_ins_CFLAGS = $(AM_CFLAGS) -g -O0 -march=octeon2

Not all compilers will accept 'octeon2' flag. Make sure the compiler understands it, and if so, then compile the test.
This may need some checks in confiure.ac.


Please clean up the patch per the code style in the Valgrind. There may be
inconsistency in the code style, but try to:

1) remove trailing spaces
2) add spaces where needed
[e.g. you are missing them in each of the following lines]
+    switch(opc1){
+   } /* opc1 0x1C ends here*/
+     } /* opc1 = 0x1F & opc2 = 0xA (LX) ends here*/
+          if (VEX_MIPS_COMP_ID(archinfo->hwcaps) == VEX_PRID_COMP_CAVIUM){
+ 	cvm_lx_ins\
3) remove use of tabs
4) align line delimiters such as '\' (e.g. see #define TEST1(instruction, offset, mem))
5) do correct indentation everywhere

Thanks.

I also missed to say that ldx is MIPS64 DSP instruction, so this instruction
should be treated differently. Have a separate test file for it, so it can be
tested on 64-bit platforms that support DSP ASE and not Cavium only.

(In reply to comment #4)
> Couple of general remarks:
> 
> - Please avoid attaching archives, rather attach plain text patches.
> - Rebase your patch to the ToT
Files have been attached separately now.  Patch has been rebased with ToT (revision 13752)
 
> Have you tested your patch on both LE and BE MIPS64? If not, can you please
> do it and add if anything is missing for it?
Test results have been verified on a BE MIPS64 OCTEON board. LE functionality has been manually verified.

> > + cvm_lx_ins_CFLAGS = $(AM_CFLAGS) -g -O0 -march=octeon2
> 
> Not all compilers will accept 'octeon2' flag. Make sure the compiler
> understands it, and if so, then compile the test.
> This may need some checks in confiure.ac.
> 
A check has been added for octeon in configure.ac (added in updated patch file)

> 
> Please clean up the patch per the code style in the Valgrind. There may be
> inconsistency in the code style, but try to:
> 
> 1) remove trailing spaces
> 2) add spaces where needed
> [e.g. you are missing them in each of the following lines]
> +    switch(opc1){
> +   } /* opc1 0x1C ends here*/
> +     } /* opc1 = 0x1F & opc2 = 0xA (LX) ends here*/
> +          if (VEX_MIPS_COMP_ID(archinfo->hwcaps) == VEX_PRID_COMP_CAVIUM){
> + 	cvm_lx_ins\
> 3) remove use of tabs
> 4) align line delimiters such as '\' (e.g. see #define TEST1(instruction,
> offset, mem))
> 5) do correct indentation everywhere
> 
Patch has been cleaned according to valgrind code style.

> Thanks.

(In reply to comment #5)
> I also missed to say that ldx is MIPS64 DSP instruction, so this instruction
> should be treated differently. Have a separate test file for it, so it can be
> tested on 64-bit platforms that support DSP ASE and not Cavium only.
Separate test, vgtest and exp files have been added for "ldx" instruction 
(test name : LoadIndexedInstructions.c).

Created attachment 84036 [details]
Adds support for cvm MIPS Load Indexed instructions

******************  PRE-REQUISITES   *****************

----Testing Enviroment specification:-----
																			
SDK             3.0 with new tool chain																		
Tool-chain	tool-121004																		
gcc version	4.7																		
glibc version	2.16																		
kernel version	3.4.27-rt37-Cavium-Octeon																		
cpu info	Cavium Octeon II V0.1																		
MotherBoard	OCTEON_CN63XX																		

valgrind 3.10.0 	r13752 release 13752
command to checkout: svn co -r 13752 svn://svn.valgrind.org/valgrind/trunk valgrind

******************  Applying patch   *****************

copy patch file to valgrind folder and following command should be run to apply patch.
run patch -p2 -i valgrind_bug326444_10_Dec_2013.patch 

******************  Files patched   *****************
patch file configure.ac
patch file none/tests/mips64/Makefile.am
patch file tests/mips_features.c
patch file VEX/priv/guest_mips_toIR.c

********  Instructions added (CVM MIPS) ******
- lbux
- lwx
- lbx
- lhux
- lwux
- ldx

Created attachment 84037 [details]
Test Cases For Load Indexed Instructions

Test for all load indexed instructions except "ldx" which has been treated differently.

Created attachment 84038 [details]
Expected Output of cvm_lx_ins

Created attachment 84039 [details]
VGTEST file for cvm_lx_ins

Created attachment 84040 [details]
Test Cases For LDX instruction

Created attachment 84041 [details]
Output File for LDX

Created attachment 84042 [details]
VGTEST file for LDX

I tried the latest patches from Bug 326444 & 327223. It solved the invalid instruction error on octeon but I'm not getting proper stack trace and logs when I tried to run simple program.

configure options:   ./configure --host=mips64-target-linux-gnu --build=x86_64-crosscompile-linux-gnu

II'm 

root@sasi:/root> valgrind ./a.out 1
==4236== Memcheck, a memory error detector
==4236== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==4236== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==4236== Command: ./a.out 1
==4236==
==4236== Conditional jump or move depends on uninitialised value(s)
==4236==    at 0x401AD20: ??? (in /lib64/ld-2.11.1.so)
==4236==    by 0x4008EA0: ??? (in /lib64/ld-2.11.1.so)
==4236==
==4236== Conditional jump or move depends on uninitialised value(s)
==4236==    at 0x401AEB0: ??? (in /lib64/ld-2.11.1.so)
==4236==    by 0x4006204: ??? (in /lib64/ld-2.11.1.so)
==4236==
==4236== Conditional jump or move depends on uninitialised value(s)
==4236==    at 0x401AEB0: ??? (in /lib64/ld-2.11.1.so)
==4236==    by 0x400C7BC: ??? (in /lib64/ld-2.11.1.so)
==4236==
      4236:
==4236== Invalid read of size 4
==4236==    at 0x400D148: ??? (in /lib64/ld-2.11.1.so)
==4236==    by 0x4004B4C: ??? (in /lib64/ld-2.11.1.so)
==4236==  Address 0x50 is not stack'd, malloc'd or (recently) free'd
==4236==
==4236==
==4236== Process terminating with default action of signal 11 (SIGSEGV)
==4236==  Access not within mapped region at address 0x50
==4236==    at 0x400D148: ??? (in /lib64/ld-2.11.1.so)
==4236==    by 0x4004B4C: ??? (in /lib64/ld-2.11.1.so)
==4236==  If you believe this happened as a result of a stack
==4236==  overflow in your program's main thread (unlikely but
==4236==  possible), you can try to increase the size of the
==4236==  main thread stack using the --main-stacksize= flag.
==4236==  The main thread stack size used in this run was 8388608.
==4236== Jump to the invalid address stated on the next line
==4236==    at 0x9E0: ???
==4236==    by 0x40338F0: _vgnU_freeres (vg_preloaded.c:63)
==4236==    by 0x4004B50: ??? (in /lib64/ld-2.11.1.so)
==4236==  Address 0x9e0 is not stack'd, malloc'd or (recently) free'd
==4236==
==4236==
==4236== Process terminating with default action of signal 11 (SIGSEGV)
==4236==  Bad permissions for mapped region at address 0x9E0
==4236==    at 0x9E0: ???
==4236==    by 0x40338F0: _vgnU_freeres (vg_preloaded.c:63)
==4236==    by 0x4004B50: ??? (in /lib64/ld-2.11.1.so)
==4236==
==4236== HEAP SUMMARY:
==4236==     in use at exit: 0 bytes in 0 blocks
==4236==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==4236==
==4236== All heap blocks were freed -- no leaks are possible
==4236==
==4236== For counts of detected and suppressed errors, rerun with: -v
==4236== Use --track-origins=yes to see where uninitialised values come from
==4236== ERROR SUMMARY: 5 errors from 5 contexts (suppressed: 0 from 0)
Segmentation fault

@ Sasi

Do you have libc library with debug info on your system?
You can install this library on debian with:

$ sudo apt-get install libc6-dbg

You can try to run your program with:
$ valgrind --run-libc-freeres=no ./a.out 1

(In reply to comment #16)
> @ Sasi
> 
> Do you have libc library with debug info on your system?
> You can install this library on debian with:
> 
> $ sudo apt-get install libc6-dbg
> 
> You can try to run your program with:
> $ valgrind --run-libc-freeres=no ./a.out 1

@Dejan Thanks. I installed glibc debug but getting access permission issue. I'm running as root and have 32G memory (free mem 31568M)

root@sasi:/root> valgrind  ./a.out 1
==1363== Memcheck, a memory error detector
==1363== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==1363== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info
==1363== Command: ./a.out 1
==1363==
      1363:
==1363==
==1363== Process terminating with default action of signal 11 (SIGSEGV)
==1363==  Access not within mapped region at address 0x50
==1363==    at 0x400D148: _dl_relocate_object (dl-machine.h:713)
==1363==    by 0x4004B50: dl_main (rtld.c:2227)
==1363==    by 0x4019188: _dl_sysdep_start (dl-sysdep.c:243)
==1363==    by 0x40021A4: _dl_start_final (rtld.c:333)
==1363==    by 0x40023E4: _dl_start (rtld.c:561)
==1363==    by 0x4001C0C: __start (in /lib64/ld-2.11.1.so)
==1363==  If you believe this happened as a result of a stack
==1363==  overflow in your program's main thread (unlikely but
==1363==  possible), you can try to increase the size of the
==1363==  main thread stack using the --main-stacksize= flag.
==1363==  The main thread stack size used in this run was 8388608.
==1363== Jump to the invalid address stated on the next line
==1363==    at 0x9E0: ???
==1363==    by 0x40338F0: _vgnU_freeres (vg_preloaded.c:63)
==1363==    by 0x4004B50: dl_main (rtld.c:2227)
==1363==    by 0x4021D44: ???
==1363==  Address 0x9e0 is not stack'd, malloc'd or (recently) free'd
==1363==
==1363==
==1363== Process terminating with default action of signal 11 (SIGSEGV)
==1363==  Bad permissions for mapped region at address 0x9E0
==1363==    at 0x9E0: ???
==1363==    by 0x40338F0: _vgnU_freeres (vg_preloaded.c:63)
==1363==    by 0x4004B50: dl_main (rtld.c:2227)
==1363==    by 0x4021D44: ???
==1363==
==1363== HEAP SUMMARY:
==1363==     in use at exit: 0 bytes in 0 blocks
==1363==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1363==
==1363== All heap blocks were freed -- no leaks are possible
==1363==
==1363== For counts of detected and suppressed errors, rerun with: -v
==1363== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 4 from 4)
Segmentation fault
root@sasi:/root>

Patches attached to this bug have been committed (with some modifications)
in several patches.

VEX: r2811, r2819
VALGRIND: r13782, r13783, r13786, r13805, r13808, r13809

This has been tested on Cavium Octeon II boards with MIPS64r2 Debian Linux.

@Zahid Anwar
Let me know if anything is missed or you have any comments here.

@everyone
If you have a general issue on Cavium boards (not related to load-indexed
instructions), please open a new issue.

Marking as fixed as discussed with Petar.

Hi  Petar,

I have met issue related to load-indexed instructions so please refer the terminal information on my MIPS 64 Octeon II board:

valgrind ls -l
==17023== Memcheck, a memory error detector
==17023== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==17023== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==17023== Command: ls -l
==17023==
Error occured while trying to decode MIPS32 DSP instruction.
Your platform probably doesn't support MIPS32 DSP ASE.
vex mips->IR: unhandled instruction bytes: 0x7C 0xE2 0x12 0xA
==17023== valgrind: Unrecognised instruction at address 0x4016a0c.
==17023==    at 0x4016A0C: ??? (in /lib64/ld-2.9.so)
==17023==    by 0x4002914: ??? (in /lib64/ld-2.9.so)
==17023==    by 0x40031E4: ??? (in /lib64/ld-2.9.so)
==17023==    by 0x400246C: ??? (in /lib64/ld-2.9.so)
==17023== Your program just tried to execute an instruction that Valgrind
==17023== did not recognise.  There are two possible reasons for this.
==17023== 1. Your program has a bug and erroneously jumped to a non-code
==17023==    location.  If you are running Memcheck and you just saw a
==17023==    warning about a bad jump, it's probably your program's fault.
==17023== 2. The instruction is legitimate but Valgrind doesn't handle it,
==17023==    i.e. it's Valgrind's fault.  If you think this is the case or
==17023==    you are not sure, please let us know and we'll try to fix it.
==17023== Either way, Valgrind will now raise a SIGILL signal which will
==17023== probably kill your program.
==17023==
==17023== Process terminating with default action of signal 4 (SIGILL)
==17023==  Illegal opcode at address 0x4016A0C
==17023==    at 0x4016A0C: ??? (in /lib64/ld-2.9.so)
==17023==    by 0x4002914: ??? (in /lib64/ld-2.9.so)
==17023==    by 0x40031E4: ??? (in /lib64/ld-2.9.so)
==17023==    by 0x400246C: ??? (in /lib64/ld-2.9.so)
==17023==
==17023== HEAP SUMMARY:
==17023==     in use at exit: 0 bytes in 0 blocks
==17023==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==17023==
==17023== All heap blocks were freed -- no leaks are possible
==17023==
==17023== For counts of detected and suppressed errors, rerun with: -v
==17023== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Illegal instruction

Reproducible: Always

Thank you and regards,
Vien Mai.

(In reply to comment #20)
> Hi  Petar,
> 
> I have met issue related to load-indexed instructions so please refer the
> terminal information on my MIPS 64 Octeon II board:
> 
> valgrind ls -l
> ==17023== Memcheck, a memory error detector
> ==17023== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==17023== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
> ==17023== Command: ls -l
> ==17023==
> Error occured while trying to decode MIPS32 DSP instruction.
> Your platform probably doesn't support MIPS32 DSP ASE.
> vex mips->IR: unhandled instruction bytes: 0x7C 0xE2 0x12 0xA
> ==17023== valgrind: Unrecognised instruction at address 0x4016a0c.
> ==17023==    at 0x4016A0C: ??? (in /lib64/ld-2.9.so)
> ==17023==    by 0x4002914: ??? (in /lib64/ld-2.9.so)
> ==17023==    by 0x40031E4: ??? (in /lib64/ld-2.9.so)
> ==17023==    by 0x400246C: ??? (in /lib64/ld-2.9.so)
> ==17023== Your program just tried to execute an instruction that Valgrind
> ==17023== did not recognise.  There are two possible reasons for this.
> ==17023== 1. Your program has a bug and erroneously jumped to a non-code
> ==17023==    location.  If you are running Memcheck and you just saw a
> ==17023==    warning about a bad jump, it's probably your program's fault.
> ==17023== 2. The instruction is legitimate but Valgrind doesn't handle it,
> ==17023==    i.e. it's Valgrind's fault.  If you think this is the case or
> ==17023==    you are not sure, please let us know and we'll try to fix it.
> ==17023== Either way, Valgrind will now raise a SIGILL signal which will
> ==17023== probably kill your program.
> ==17023==
> ==17023== Process terminating with default action of signal 4 (SIGILL)
> ==17023==  Illegal opcode at address 0x4016A0C
> ==17023==    at 0x4016A0C: ??? (in /lib64/ld-2.9.so)
> ==17023==    by 0x4002914: ??? (in /lib64/ld-2.9.so)
> ==17023==    by 0x40031E4: ??? (in /lib64/ld-2.9.so)
> ==17023==    by 0x400246C: ??? (in /lib64/ld-2.9.so)
> ==17023==
> ==17023== HEAP SUMMARY:
> ==17023==     in use at exit: 0 bytes in 0 blocks
> ==17023==   total heap usage: 0 allocs, 0 frees, 0 bytes allocated
> ==17023==
> ==17023== All heap blocks were freed -- no leaks are possible
> ==17023==
> ==17023== For counts of detected and suppressed errors, rerun with: -v
> ==17023== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
> Illegal instruction
> 
> Reproducible: Always
> 
> Thank you and regards,
> Vien Mai.

@Vien Mai
Have you tried to checkout the latest Valgrind from SVN and use it?
If not, please do so.

If the problem persists, please open a new issue, indicate what revision
you are using, and add information that you get from 'cat /proc/cpuinfo'.

Thanks.

Hi Peter,

Thank you for your instruction. After checkout latest code, load indexed instruction problems are solved.
However, I met another issue and will open another bug report after trying few more times.

Thank you and regards,
Vien Mai.