Summary: | Cavium MIPS Octeon Specific Load Indexed Instructions | ||
---|---|---|---|
Product: | [Developer tools] valgrind | Reporter: | Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan <zahid.anwar> |
Component: | vex | Assignee: | Julian Seward <jseward> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | dejanjevtic87, florian, mips32r2, sasikanth.v19, vienmai2000 |
Priority: | NOR | ||
Version: | 3.9.0.SVN | ||
Target Milestone: | --- | ||
Platform: | Debian stable | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: |
Add support cavium octeon specific Load Indexed instructions
Test Cases Output File Adds support for cvm MIPS Load Indexed instructions Test Cases For Load Indexed Instructions Expected Output of cvm_lx_ins VGTEST file for cvm_lx_ins Test Cases For LDX instruction Output File for LDX VGTEST file for LDX |
Description
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-10-22 14:18:46 UTC
Comment 1
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-10-22 14:25:02 UTC
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
Comment 2
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-10-22 14:29:02 UTC
Created attachment 83023 [details]
Test Cases
Comment 3
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-10-22 14:29:39 UTC
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.
Comment 6
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-12-11 13:44:16 UTC
(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.
Comment 7
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-12-11 13:50:27 UTC
(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).
Comment 8
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-12-11 13:55:05 UTC
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
Comment 9
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-12-11 13:59:14 UTC
Created attachment 84037 [details]
Test Cases For Load Indexed Instructions
Test for all load indexed instructions except "ldx" which has been treated differently.
Comment 10
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-12-11 14:00:26 UTC
Created attachment 84038 [details]
Expected Output of cvm_lx_ins
Comment 11
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-12-11 14:01:10 UTC
Created attachment 84039 [details]
VGTEST file for cvm_lx_ins
Comment 12
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-12-11 14:02:27 UTC
Created attachment 84040 [details]
Test Cases For LDX instruction
Comment 13
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-12-11 14:03:00 UTC
Created attachment 84041 [details]
Output File for LDX
Comment 14
Dr. Zahid Anwar, School of Electrical Engg. & Computer Science, National Univ. of Sciences & Technology, Islamabad, Pakistan
2013-12-11 14:03:32 UTC
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. |