Created attachment 58853 [details]
tarball with full patch for MIPS support
The patch was large, so a tar ball is created.
The patches are for MIPS32, little endian. (In reply to comment #1) > Created an attachment (id=58853) [details] > tarball with full patch for MIPS support FTR (for anybody wanting to try this out), it applies against valgrind r11570 and vex r2104. You can get a suitable tree like this svn co svn://svn.valgrind.org/valgrind/trunk cd trunk svn up -r11570 cd VEX svn up -r2104 cd .. # now apply the patch (In reply to comment #1) > Created an attachment (id=58853) [details] > tarball with full patch for MIPS support Build fails like this: gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_mips=1 -DVGO_linux=1 -DVGP_mips_linux=1 -Ipriv -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wbad-function-cast -Wcast-qual -Wcast-align -fstrict-aliasing -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT libvex_mips_linux_a-guest_mips_helpers.o -MD -MP -MF .deps/libvex_mips_linux_a-guest_mips_helpers.Tpo -c -o libvex_mips_linux_a-guest_mips_helpers.o `test -f 'priv/guest_mips_helpers.c' || echo './'`priv/guest_mips_helpers.c /tmp/ccWf1yw6.s: Assembler messages: /tmp/ccWf1yw6.s:804: Error: illegal operands `mfc0 $2,$30,6' /tmp/ccWf1yw6.s:821: Error: illegal operands `mfc0 $2,$29,6' /tmp/ccWf1yw6.s:838: Error: illegal operands `mfc0 $2,$28,6' /tmp/ccWf1yw6.s:855: Error: illegal operands `mfc0 $2,$27,6' /tmp/ccWf1yw6.s:872: Error: illegal operands `mfc0 $2,$26,6' /tmp/ccWf1yw6.s:889: Error: illegal operands `mfc0 $2,$25,6' /tmp/ccWf1yw6.s:906: Error: illegal operands `mfc0 $2,$24,6' /tmp/ccWf1yw6.s:923: Error: illegal operands `mfc0 $2,$23,6' /tmp/ccWf1yw6.s:940: Error: illegal operands `mfc0 $2,$22,6' [.. hundreds more omitted ..] $ uname -a Linux mipsel 2.6.32-5-4kc-malta #1 Tue Mar 8 00:43:27 UTC 2011 mips GNU/Linux $ cat /etc/issue Debian GNU/Linux 6.0 \n \l $ cat /proc/cpuinfo system type : MIPS Malta processor : 0 cpu model : MIPS 24Kc V0.0 FPU V0.0 BogoMIPS : 899.07 wait instruction : yes microsecond timers : yes tlb_entries : 16 extra interrupt vector : yes hardware watchpoint : yes, count: 1, address/irw mask: [0x0ff8] ASEs implemented : mips16 shadow register sets : 1 core : 0 VCED exceptions : not available VCEI exceptions : not available Which GCC version has caused the error? If you are not using 4.5.1 or later GCC, you need to call configure with -mips32r2 -mplt, i.e. ./configure CFLAGS="-mips32r2 -mplt" Hi Perter, I check my mail recently I try your tarball, I have this message : ==459== Memcheck, a memory error detector ==459== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==459== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info ==459== Command: middleware ==459== valgrind: m_debuginfo/readelf.c:1432 (vgModuleLocal_read_elf_debug_info): Assertion 'rw_svma_limit != 0' failed. ==459== at 0x380301A0: report_and_quit (m_libcassert.c:218) ==459== by 0x380303A7: vgPlain_assert_fail (m_libcassert.c:292) ==459== by 0x3805F427: vgModuleLocal_read_elf_debug_info (readelf.c:1197) ==459== by 0x3805C893: vgPlain_di_notify_mmap (debuginfo.c:822) ==459== by 0x3808020F: vgModuleLocal_generic_PRE_sys_mmap (syswrap-generic.c:2064) ==459== by 0x380A74B7: vgSysWrap_mips_linux_sys_mmap_before (syswrap-mips-linux.c:1053) ==459== by 0x38071BC3: vgPlain_client_syscall (syswrap-main.c:1503) ==459== by 0x3806DCFF: handle_syscall (scheduler.c:895) ==459== by 0x3806EC8B: vgPlain_scheduler (scheduler.c:1091) ==459== by 0x3809C51F: run_a_thread_NORETURN (syswrap-linux.c:94) ==459== by 0x3809C91F: vgPlain_main_thread_wrapper_NORETURN (syswrap-linux.c:312) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==459== at 0x4001248: ??? (in /lib/ld-uClibc-0.9.29.so) Created attachment 60274 [details]
all tools ko
I can deliver you some logs if needed... Regards, Frédéric *** Bug 276233 has been marked as a duplicate of this bug. *** Comment on attachment 58853 [details]
tarball with full patch for MIPS support
New patch will be provided.
Comment on attachment 58852 [details]
changes to the existing files (patch 1)
Obsolete now. Will be replaced with another patch.
Hello everyone,
here are the updated patches which provide MIPS/Linux support for Valgrind.
Two patches will be attached:
1. existing-files-changes.tar.bz2
2. r11845_mips.tar.bz2
The first patch has the changes only to the existing files, so the review can be done more easily.
The second patch is a complete patch (it contains changes both to the existing files and new files), and it can be applied to the revision 11845 from the main Valgrind trunk. If you are looking to use Valgrind for MIPS, download this patch.
If you want to apply the patch and build Valgrind natively, here are brief instructions:
$ svn export -r 11845 svn://svn.valgrind.org/valgrind/trunk
$ cd trunk
$ patch -p0 < ../r11845_mips.diff
$ ./autogen.sh
$ ./configure
$ make
$ make install
You can also use the cross-toolchain, if you prefer it.
Additional configure options:
./configure --host=mipsel-linux-gnu --prefix=<path_to_install_directory>
[--with-pagesize=<4|16|64>]
* --host=mips-linux-gnu is necessary only if Valgrind is built on platform
other then MIPS, tools for building MIPS application have to be in PATH.
* --with-pagesize option is used to set default PAGE SIZE. If option is not
used, PAGE SIZE is set to value default for platform where Valgrind is
built. Possible values are 4, 16 of 64 and represents size in kilobytes.
* --host=mips-linux-gnu is necessary if you compile it with cross toolchain
compiler for big endian platform.
* --host=mipsel-linux-gnu is necessary if you compile it with cross toolchain
compiler for litle endian platform.
* If you are compiling Valgrind with gcc version older then gcc (GCC) 4.5.1
you must specify CFLAGS="-mips32r2 -mplt", e.g.
./configure --prefix=<path_to_install_directory>
CFLAGS="-mips32r2 -mplt"
This patch is applicable for MIPS32r2 instruction set. It supports both little-endian and big-endian cores. It has been tested with different programs on different MIPS boards. The list of tested programs include Firefox and QtCreator.
Created attachment 62001 [details]
the changes to the existing files - for code review
These are the changes to the existing files only. To be used for code-review.
Created attachment 62002 [details]
complete patch - apply it to r11845 and use it.
This is a full patch, and it should be applied to r11845 from the Valgrind trunk. It has support for MIPS32r2 LE/BE.
The path r11845 seams support little-endian. But my chip is big-endian. I want to make sure that whether valgrind supports MIPS32 big-endian? The latest patch supports both little endian and big endian platforms. I try to compile valgrind with cross-compiler on a x86 Linux by typing:
./configure --host=mips-linux-uclibc CFLAGS="-mips32r2 -mplt"
the result seams failed:
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for mips-linux-uclibc-strip... mips-linux-uclibc-strip
checking whether to enable maintainer-specific portions of Makefiles... no
checking whether ln -s works... yes
checking for mips-linux-uclibc-gcc... mips-linux-uclibc-gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
I go to the config.log and find:
configure:1400: checking for a BSD-compatible install
configure:1455: result: /usr/bin/install -c
configure:1466: checking whether build environment is sane
configure:1509: result: yes
configure:1574: checking for gawk
configure:1590: found /usr/bin/gawk
configure:1600: result: gawk
configure:1610: checking whether make sets $(MAKE)
configure:1630: result: yes
configure:1706: checking for mips-linux-uclibc-strip
configure:1722: found /opt/mcp/uc_mips/bin//mips-linux-uclibc-strip
configure:1732: result: mips-linux-uclibc-strip
configure:1799: checking whether to enable maintainer-specific portions of Makefiles
configure:1808: result: no
configure:1829: checking whether ln -s works
configure:1833: result: yes
configure:1848: checking for mips-linux-uclibc-gcc
configure:1864: found /opt/mcp/uc_mips/bin//mips-linux-uclibc-gcc
configure:1874: result: mips-linux-uclibc-gcc
configure:2156: checking for C compiler version
configure:2159: mips-linux-uclibc-gcc --version </dev/null >&5
mips-linux-uclibc-gcc (GCC) 3.4.4
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
configure:2162: $? = 0
configure:2164: mips-linux-uclibc-gcc -v </dev/null >&5
Reading specs from /opt/mcp/uc_mips/lib/gcc/mips-linux-uclibc/3.4.4/specs
Configured with: /usr/src/mcp/mcp5/BUILD/gcc/configure --prefix=/opt/mcp/uc_mips --target=mips-linux-uclibc --disable-nls --enable-cross --disable-libmudflap --disable-tui --with-arch=4kc --with-tune=4kc --with-prefer-nopic --enable-cross --enable-shared --with-system-zlib --disable-__cxa_atexit --disable-threads --enable-languages=c,c++
Thread model: single
gcc version 3.4.4
configure:2167: $? = 0
configure:2169: mips-linux-uclibc-gcc -V </dev/null >&5
mips-linux-uclibc-gcc: `-V' option must have argument
configure:2172: $? = 1
configure:2195: checking for C compiler default output file name
configure:2198: mips-linux-uclibc-gcc -Wno-long-long -mips32r2 -mplt conftest.c >&5
cc1: error: invalid option `plt'
configure:2201: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "Valgrind"
| #define PACKAGE_TARNAME "valgrind"
| #define PACKAGE_VERSION "3.7.0.SVN"
| #define PACKAGE_STRING "Valgrind 3.7.0.SVN"
| #define PACKAGE_BUGREPORT "valgrind-users@lists.sourceforge.net"
| #define PACKAGE "valgrind"
| #define VERSION "3.7.0.SVN"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2240: error: C compiler cannot create executables
See `config.log' for more details.
This seams the configure will compile a mips binary file and try to run it on the builder platform, but my platform is a x86 Linux, the binary file cannot run on it. How can I deal with it just to complete the compile process?
@NASa MIPS port of Valgrind has been tested with recent cross-toolchain from CodeSourcery and with native toolchains. I would suggest you to use either CS cross-toolchain or a native toolchain. @Petar Could please show me how to ./configure by using CS cross-toolchain to build MIPS binary files on a x86 Linux platform? Install CS cross toolchain, make sure the binaries are in the PATH, and run: ./configure --host=mips-linux-gnu --with-pagesize=n where n is pagesize of the target MIPS-based platform (n can be 4, 16 or 64). Hi It seems better, Currently I have a crash at the init, ==388== Process terminating with default action of signal 10 (SIGBUS) ==388== at 0x4D96710: __pthread_initialize_minimal (in /lib/libpthread-0.9.29.so) ==388== by 0x4DD18CB: __uClibc_init (in /lib/libuClibc-0.9.29.so) ==388== Bus error But I have modified the toolchain to have a function WIFCONTINUED needed by the new coregrind. So I doesn't know if the bug is in my libpthread / in my toolchain modification or valgrind. Ps : I don't use the "-mips32r2 -mplt " argument in my setup. Best Regards Thanks Created attachment 62975 [details]
Log file - Patch application logs
There were some issues while applying the patch on the trunk. This log captures those issues. The resulting directory didn't contain the configure script.
I tried installing the patch "r11845_mips.tar.bz2" over specified versions of trunk. There were some issues while applying the patch on the trunk. The attached log captures those issues. The resulting directory didn't contain the configure script. Any help in this regard will be greatly appreciated. @gautam.dawar it seems you downloaded a wrong revision from the trunk. For the latest patch, it should not be revision 11570 (as seen in your log), but 11845. The revision number will likely change with the next updates as well. @Petar,
Thanks for your inputs. Now I am able to apply the patch successfully on revision 11845. But on running make command, build fails with the following errors:
ranlib libvex-mips-linux.a
make[3]: Leaving directory `/home/gautam/trunk/VEX'
make[2]: Leaving directory `/home/gautam/trunk/VEX'
Making all in coregrind
make[2]: Entering directory `/home/gautam/trunk/coregrind'
make all-am
make[3]: Entering directory `/home/gautam/trunk/coregrind'
gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_mips=1 -DVGO_linux=1 -DVGP_mips_linux=1 -I../coregrind -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DVG_PLATFORM="\"mips-linux\"" -m32 -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT libcoregrind_mips_linux_a-m_commandline.o -MD -MP -MF .deps/libcoregrind_mips_linux_a-m_commandline.Tpo -c -o libcoregrind_mips_linux_a-m_commandline.o `test -f 'm_commandline.c' || echo './'`m_commandline.c
In file included from pub_core_basics.h:40,
from m_commandline.c:31:
../include/pub_tool_basics.h:290:4: error: #error Unknown arch
In file included from ../include/pub_tool_vki.h:49,
from pub_core_vki.h:44,
from m_commandline.c:32:
../include/vki/vki-linux.h:1409:2: error: #error edit for your odd byteorder.
In file included from ../include/pub_tool_vki.h:49,
from pub_core_vki.h:44,
from m_commandline.c:32:
../include/vki/vki-linux.h:1415: warning: parameter names (without types) in function declaration
../include/vki/vki-linux.h:1415: error: field ‘VKI_PADDED’ declared as a function
make[3]: *** [libcoregrind_mips_linux_a-m_commandline.o] Error 1
make[3]: Leaving directory `/home/gautam/trunk/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/gautam/trunk/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/gautam/trunk'
make: *** [all] Error 2
I am running this on Ubuntu (Linux 2.6.28-11-generic #42-Ubuntu SMP Fri Apr 17 01:57:59 UTC 2009 i686 GNU/Linux)where following commands listed in the configure script are not available:
/bin/arch
/usr/bin/arch -k
/usr/convex/getsysinfo
/usr/bin/hostinfo
/bin/machine
/usr/bin/oslevel
/bin/universe
I created a shell script which runs "uname -m" and saved it as /bin/arch and /usr/bin/arch. But even after this, the first two commands evaluate to i686 but the rest return unknown and finally build fails.
Also, even after exporting the path of mips tool-chain in the PATH env variable, on running the configure script I observe the following in the config.log:
checking for mipsel-linux-g++... no
checking for mipsel-linux-c++... no
checking for mipsel-linux-gpp... no
checking for mipsel-linux-aCC... no
checking for mipsel-linux-CC... no
checking for mipsel-linux-cxx... no
checking for mipsel-linux-cc++... no
checking for mipsel-linux-cl.exe... no
checking for mipsel-linux-FCC... no
which can be accessed from the shell I am running the configure script.
Kindly suggest on how to proceed further.
@gautam.dawar
> checking for mipsel-linux-g++... no
This seems to be indicating your issue.
1. What compiler are you using?
2. Provide the command line with which you run the configure script.
@Petar 1. Compiler I am using: mipsel-linux-gcc The location of these mips tools directory has been exported through the PATH variable. 2. Command line used to run the configure script: sudo ./configure --host=mipsel-linux --prefix=/home/gautam/trunk sudo ./configure --host=mipsel-linux I tried running the configure script both with and without specifying the prefix directory. But what I feel is that the problem lies with the certain commands specified in the configure script which are not available on the host: /bin/arch /usr/bin/arch -k /usr/convex/getsysinfo /usr/bin/hostinfo /bin/machine /usr/bin/oslevel /bin/universe Of these, /bin/arch and /usr/bin/arch -k have been made to return i686 but others still are not available due to which probably the build fails as: ../include/pub_tool_basics.h:290:4: error: #error Unknown arch Regards, Gautam Just to add to this that mipsel-linux-g++ is also available in the same directory as mips-linux-gcc. (In reply to comment #27) > @Petar > > 1. Compiler I am using: mipsel-linux-gcc > The location of these mips tools directory has been exported through the PATH > variable. > > 2. Command line used to run the configure script: > sudo ./configure --host=mipsel-linux --prefix=/home/gautam/trunk > sudo ./configure --host=mipsel-linux > > I tried running the configure script both with and without specifying the > prefix > directory. > > But what I feel is that the problem lies with the certain commands specified in > the configure script which are not available on the host: > > /bin/arch > /usr/bin/arch -k > /usr/convex/getsysinfo > /usr/bin/hostinfo > /bin/machine > /usr/bin/oslevel > /bin/universe > > Of these, /bin/arch and /usr/bin/arch -k have been made to return i686 but > others still are not available due to which probably the build fails as: > > ../include/pub_tool_basics.h:290:4: error: #error Unknown arch > > Regards, > Gautam @Gautam
> 1. Compiler I am using: mipsel-linux-gcc
which one?
Btw, have you run the autogen.sh? Has it been executed successfully?
Can you share you config.log? You can not continue the steps, if one of the previous fails.
You need to debug this issue on your system, check your logs, to see what may be missing on your platform, etc.
@Petar Yes the autogen.sh ran successfully. The compiler (tool-chain) directory has been exported in the PATH variable as can be seen below: gautam@agnity-desktop:~/trunk$ echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/opt/buildroot-gcc342/bin gautam@agnity-desktop:~/trunk$ /opt/buildroot-gcc342/bin/mipsel-linux-g++ --version mipsel-linux-g++ (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. gautam@agnity-desktop:~/trunk$ gautam@agnity-desktop:~/trunk$ mipsel-linux-g++ --version mipsel-linux-g++ (GCC) 3.4.2 Copyright (C) 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The config.log is attached for your reference. Thanks, Gautam Created attachment 63207 [details]
config.log for failure scenario
@Gautam I do not think you should run ./configure with sudo, it changes your $PATH. That may be the issue for you case. As I said, this is configure/build issue specific to your machine, not Valgrind or MIPS issue. You may also think about switching to newer compiler version. Whether there are plans to support N32/64 ABIs? What about hardware floating point support? @Dmitry mips32 hard-float is already supported in the patch. As of MIPS64 support, some work has already been done in that direction, but it is not yet available. hi, I am trying to cross-compile for mips platform on my fedora core machine. I have downloaded the trunk from svn and applied the patch. I ran the following command: $ ./autogen.sh export CC = /opt/sciatl/1.0.3.1/bin/mips-linux-gcc export LD = /opt/sciatl/1.0.3.1/bin/mips-linux-ld export AR = /opt/sciatl/1.0.3.1/bin/mips-linux-ar ./configure --host=mips-linux make Now when i am invoking make i am getting following errors: mv -f .deps/libcoregrind_mips_linux_a-m_debugger.Tpo .deps/libcoregrind_mips_linux_a-m_debugger.Po /opt/sciatl/1.0.3.1/bin/mips-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_mips=1 -DVGO_linux=1 -DVGP_mips_linux=1 -I../coregrind -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DVG_PLATFORM="\"mips-linux\"" -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT libcoregrind_mips_linux_a-m_debuglog.o -MD -MP -MF .deps/libcoregrind_mips_linux_a-m_debuglog.Tpo -c -o libcoregrind_mips_linux_a-m_debuglog.o `test -f 'm_debuglog.c' || echo './'`m_debuglog.c m_debuglog.c: In function âlocal_sys_write_stderrâ: m_debuglog.c:426: warning: statement with no effect m_debuglog.c: In function âlocal_sys_getpidâ: m_debuglog.c:441: warning: statement with no effect m_debuglog.c: At top level: m_debuglog.c:399: warning: âdoSyscallâ used but never defined /tmp/ccz6NGCt.s: Assembler messages: /tmp/ccz6NGCt.s:1980: Error: illegal operands `move $t3,$2' /tmp/ccz6NGCt.s:1981: Error: illegal operands `move $t4,$3' /tmp/ccz6NGCt.s:1986: Error: illegal operands `or $t5,$t5,$t5' /tmp/ccz6NGCt.s:1987: Error: illegal operands `move' make[3]: *** [libcoregrind_mips_linux_a-m_debuglog.o] Error 1 make[3]: Leaving directory `/home/sumant/trunk/coregrind' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/sumant/trunk/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/sumant/trunk' make: *** [all] Error 2 Please help (In reply to comment #35) > /tmp/ccz6NGCt.s: Assembler messages: > /tmp/ccz6NGCt.s:1980: Error: illegal operands `move $t3,$2' > /tmp/ccz6NGCt.s:1981: Error: illegal operands `move $t4,$3' > /tmp/ccz6NGCt.s:1986: Error: illegal operands `or $t5,$t5,$t5' > /tmp/ccz6NGCt.s:1987: Error: illegal operands `move' Your compiler targets n32 MIPS ABI by default. This Valgrind port is o32 and will not work with n32/64 libraries/executables. Thanks for the reply. Currently i am working on x86 machine and recently installed a mips toolchain on it.How do we know that the compiler targets n32 or o32 ?Also what changes are required if we want to port valgrind to n32? Any kind of suggestions would really be appreciated. (In reply to comment #37) > Currently i am working on x86 machine and recently installed a mips toolchain > on it.How do we know that the compiler targets n32 or o32 Try to run: [prefix]-gcc -x c /dev/null -E -C -dM | grep MIPS_SIM If you will see something like #define _MIPS_SIM _ABIO32 then your compiler targets o32 ABI by default. If you will see #define _MIPS_SIM _ABIN32 then it's n32. Most probably your GCC is configured to support multiple MIPS ABIs. Try to run your compiler with '-mabi=n32' and '-mabi=64' options and see what happens. > Also what changes > are required if we want to port valgrind to n32? In short, n32 uses another conventions to pass function arguments, which means that assembly code written for o32 will not work in most of cases. System calls interface and signal delivering is also different. You can read http://www.linux-mips.org/wiki/MIPSABIHistory for brief description of this stuff or http://math-atlas.sourceforge.net/devel/assembly/007-2816-005.pdf for technical details. I am using the following command to know the status: /opt/sciatl/1.0.3.1/bin/mips-linux-gcc -x c /dev/null -E -C -dM | grep MIPS_SIM #define _MIPS_SIM _ABIO32 It seems that the mips toolchain is of o32 ,so i think it should work since you earlier described that valgrind is ported on o32. but i am getting errrors,please help. (In reply to comment #39) > I am using the following command to know the status: > > /opt/sciatl/1.0.3.1/bin/mips-linux-gcc -x c /dev/null -E -C -dM | grep MIPS_SIM > #define _MIPS_SIM _ABIO32 > > It seems that the mips toolchain is of o32 ,so i think it should work since you > earlier described that valgrind is ported on o32. > but i am getting errrors,please help. Try to compile m_debuglog.c with '-v' gcc option and check whether gcc passes correct options to as and ld. Usually this kind of problems takes place due to broken toolchains. @sumant
> /tmp/ccz6NGCt.s:1980: Error: illegal operands `move $t3,$2'
This may be an issue with some older compilers that need explicit numbers of registers in inlined assembly, i.e. 'move $t3, $2' needs to be changed to 'move $11, $2'. That has been changed on an internal mips-valgrind-branch, and it will be included in a patch at some point in the future, but if you need it in the meantime, you can change it yourself, it should not be difficult.
That may not be the only issue you will experience if you are using an older compiler though.
@Petar Thanks for giving your input. Can you please tell me that in which file i need to do these changes ie. 'move $t3, $2' needs to be changed to 'move $11, $2' Let your compiler tell you that. That will be the easiest way. On Tue, Sep 27, 2011 at 4:50 PM, sumant <sumantgupta@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=270777 > > > > > > --- Comment #42 from sumant <sumantgupta gmail com> 2011-09-27 14:50:32 > --- > @Petar > Thanks for giving your input. > Can you please tell me that in which file i need to do these changes ie. > 'move $t3, $2' needs to be changed to 'move > $11, $2' > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. > *** Bug 265929 has been marked as a duplicate of this bug. *** Hi Petar, I have downloaded the source code from SVN as per you instructions $ svn export -r 11845 svn://svn.valgrind.org/valgrind/trunk $ cd trunk $ patch -p0 < ../r11845_mips.diff $ ./autogen.sh $ ./configure $ make $ make install We have MIPS base Lantiq route. Tool chain info /opt/toolchains/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1_2_6_20 We are success full able to start the compile for valgrind. But when it reached to compile following file : drd_clientreq.c the compilation stops. mips-linux-uclibc-gcc -DHAVE_CONFIG_H --param inline-unit-growth=900 -O1 -Wextra -Wformat-nonliteral -Wno-inline -Wno-unused-parameter -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_mips=1 -DVGO_linux=1 -DVGP_mips_linux=1 --param inline-unit-growth=900 -O1 -Wextra -Wformat-nonliteral -Wno-inline -Wno-unused-parameter -Wno-long-long -g -DGLOBAL_DEBUGGING_ENABLED=1 -DWSTL_DEBUG_OUTPUT=1 -DWSTL_RELEASE_BUILD=0 -Os -march=mips32r2 -mtune=mips32r2 -Wno-pointer-sign -fno-stack-protector -MT drd_mips_linux-drd_clientobj.o -MD -MP -MF .deps/drd_mips_linux-drd_clientobj.Tpo -c -o drd_mips_linux-drd_clientobj.o `test -f 'drd_clientobj.c' || echo './'`drd_clientobj.c cc1: warning: -Wformat-nonliteral ignored without -Wformat mv -f .deps/drd_mips_linux-drd_clientobj.Tpo .deps/drd_mips_linux-drd_clientobj.Po mips-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_mips=1 -DVGO_linux=1 -DVGP_mips_linux=1 --param inline-unit-growth=900 -O1 -Wextra -Wformat-nonliteral -Wno-inline -Wno-unused-parameter -Wno-long-long -g -DGLOBAL_DEBUGGING_ENABLED=1 -DWSTL_DEBUG_OUTPUT=1 -DWSTL_RELEASE_BUILD=0 -Os -march=mips32r2 -mtune=mips32r2 -Wno-pointer-sign -fno-stack-protector -MT drd_mips_linux-drd_clientreq.o -MD -MP -MF .deps/drd_mips_linux-drd_clientreq.Tpo -c -o drd_mips_linux-drd_clientreq.o `test -f 'drd_clientreq.c' || echo './'`drd_clientreq.c I have read the comment in the Makefile regarding # Added for MIPS arhitecture; we need to use -O1 because GCC for MIPS # can not compile drd_clientreq.c and drd_load_store.c with -O2 #DRD_CFLAGS = \ # --param inline-unit-growth=900 \ # -O2 \ # -Wextra \ # -Wformat-nonliteral \ # -Wno-inline \ # -Wno-unused-parameter DRD_CFLAGS = \ --param inline-unit-growth=900 \ -O1 \ -Wextra \ -Wformat-nonliteral \ -Wno-inline \ -Wno-unused-parameter So I tried to remove the "O2" compiler optimise options. but still I am not able to get the code to compile and move ahead. I have executed following given command /opt/toolchains/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1_2_6_20/usr/bin/mips-linux-gcc -x c /dev/null -E -C -dM | grep MIPS_SIM #define _MIPS_SIM _ABIO32 Please provide you view on what need to done to resolve this issues -Anand Moon @Anand How did you end up with -Os in the command line? If you are using CFLAGS, do not put "-Os" inside. Comment on attachment 62001 [details]
the changes to the existing files - for code review
This attachment is obsolete now. Will be replaced with another patch.
Comment on attachment 62002 [details]
complete patch - apply it to r11845 and use it.
This attachment is obsolete now. Will be replaced with another patch.
Hello everyone,
here are the updated patches which provide MIPS/Linux support for Valgrind.
Two patches will be attached:
1. existing_files_r12270_mips.diff
2. new_files_r12270_mips.diff
The first patch has the changes to the existing files only, and the second
patch includes new files only.
The patches should be applied against r12270 revision from the main Valgrind
trunk. If you are looking to use Valgrind for MIPS, download both patches.
If you want to apply the patch and build Valgrind natively, here are brief
instructions:
$ svn export -r 12270 svn://svn.valgrind.org/valgrind/trunk
$ cd trunk
$ patch -p0 < ../existing_files_r12270_mips.diff
$ patch -p0 < ../new_files_r12270_mips.diff
$ ./autogen.sh
$ ./configure
$ make
$ make install
You can also use the cross-toolchain, if you prefer it.
Additional configure options:
./configure --host=mipsel-linux-gnu --prefix=<path_to_install_directory>
[--with-pagesize=<4|16|64>]
* --host=mips-linux-gnu is necessary only if Valgrind is built on platform
other then MIPS, tools for building MIPS application have to be in PATH.
* --with-pagesize option is used to set default PAGE SIZE. If option is not
used, PAGE SIZE is set to value default for platform where Valgrind is
built. Possible values are 4, 16 of 64 and represents size in kilobytes.
* --host=mips-linux-gnu is necessary if you compile it with cross toolchain
compiler for big endian platform.
* --host=mipsel-linux-gnu is necessary if you compile it with cross toolchain
compiler for litle endian platform.
* If you are compiling Valgrind with gcc version older then gcc (GCC) 4.5.1
you must specify CFLAGS="-mips32r2 -mplt", e.g.
./configure --prefix=<path_to_install_directory>
CFLAGS="-mips32r2 -mplt"
* A recent version of CS toolchain, 4.5.2, also needs additional configure
option CC="mips-linux-gnu-gcc-4.5.2", e.g.
./configure --prefix=<path_to_install_directory>
CC="mips-linux-gnu-gcc-4.5.2"
This patch is applicable for MIPS32r2 instruction set. It supports both
little-endian and big-endian cores. It has been tested with different programs
on different MIPS boards. The list of tested programs include Firefox and
QtCreator.
Created attachment 66076 [details]
first patch to apply to r12270 for Valgrind for mips; existing files only
First of two patches that should be applied to r12270. It includes changes to existing files only.
Created attachment 66077 [details]
new mips Valgrind files for r12270 - new_files_r12270_mips_A.diff
Second patch - first half - that should be applied to r12270. It includes new files added to Valgrind.
I had to split the second patch into two smaller patches, as KDE Bug system does not allow patches larger than 1000 KB in size.
So, instead of new_files_r12270_mips.diff, now we have new_files_r12270_mips_A.diff and new_files_r12270_mips_B.diff. Hopefully, nobody is confused by this.
Apply both patches.
Created attachment 66078 [details]
new_files_r12270_mips_B.diff
Second patch - second half - that should be applied to r12270. It includes new files added to Valgrind.
Apply both new_files_r12270_mips_A.diff and new_files_r12270_mips_B.diff.
To sum up the above, three patches have to be applied. The common steps are: $ svn export -r 12270 svn://svn.valgrind.org/valgrind/trunk $ cd trunk $ patch -p0 < ../existing_files_r12270_mips.diff $ patch -p0 < ../new_files_r12270_mips_A.diff $ patch -p0 < ../new_files_r12270_mips_B.diff $ ./autogen.sh $ ./configure $ make $ make install Hi Petar, Is there some changelog information ? is it a compilation job and valgrind update ? or do you have the majors differences with the r11845 ? Best Regards, Frédéric @Frédéric No major differences. The code has been rebased to a recent version, and it includes some minor clean-up. Hi Petan, We have a modem on which we would like to run Valgrind to do test some memory leaks on our code base. It has 64 Mb ram and MIPS 32 bit arch and 16 MB flash drive. After getting the valgrind to compile on cross toolchain. As the Valgrind app's and lib's are more than able to fit in Flash, we loaded vlagrind using USB. For this we formated the USB with EXT3 filesystem and then copy all the exeutables and binary on USB. After mounting the USB on the modem. Now if we try to execute valgrind on some testapp i.e. Having some memory leak I am getting following messsage. # /var/tmp/install/bin/valgrind --tool=memcheck --leak-check=yes --show-reachable=yes --num-callers=20 --track-fds=yes /bin/testapp ==3389== Memcheck, a memory error detector ==3389== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==3389== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info ==3389== Command: /bin/testapp ==3389== DSL_CPE: Parsing script file (/etc/InfineonScripts/adsl_nonatt.scr)... ==3389== ==3389== Valgrind's memory management: out of memory: ==3389== initialiseSector(TC)'s request for 27597024 bytes failed. ==3389== 30330880 bytes have already been allocated. ==3389== Valgrind cannot continue. Sorry. ==3389== ==3389== There are several possible reasons for this. ==3389== - You have some kind of memory limit in place. Look at the ==3389== output of 'ulimit -a'. Is there a limit on the size of ==3389== virtual memory or address space? ==3389== - You have run out of swap space. ==3389== - Valgrind has a bug. If you think this is the case or you are ==3389== not sure, please let us know and we'll try to fix it. ==3389== Please note that programs can take substantially more memory than ==3389== normal when running under Valgrind tools, eg. up to twice or ==3389== more, depending on the tool. On a 64-bit machine, Valgrind ==3389== should be able to make use of up 32GB memory. On a 32-bit ==3389== machine, Valgrind should be able to use all the memory available ==3389== to a single process, up to 4GB if that's how you have your ==3389== kernel configured. Most 32-bit Linux setups allow a maximum of ==3389== 3GB per process. ==3389== ==3389== Whatever the reason, Valgrind cannot continue. Sorry. # Here is the out put of ulimit -a # ulimit -a time(seconds) unlimited file(blocks) unlimited data(kbytes) unlimited stack(kbytes) 2040 coredump(blocks) 0 memory(kbytes) unlimited locked memory(kbytes) 64 process 472 nofiles 1024 vmemory(kbytes) unlimited locks unlimited Am I still doing some thing wrong over here. How are you guy's testing valgrid. Please share the testcase. Please share your thought on this. -Anand Moon @Anand Moon This seems to be a lack-of-memory issue. Valgrind uses a lot of memory, and we have never tested Valgrind with less than 128MB of RAM. Using 256MB of RAM would be preferred. If your system can not be upgraded with RAM memory, I would advise using a swap file. Hi Petar, The SWAP partition worked for me. I have created 2GB of SWAP Space on my USB flash drive. And now I am able to run valgrind. But I am not valgrind is not detecting any error. I have done too many malloc and no free in my testapp.c but no error are getting detected. Here is the output. # /var/tmp/install/bin/valgrind -v --tool=memcheck --leak-check=yes --workaround-gcc296-bugs=yes --run-libc-freeres=no --vgdb=yes /bin/testap p ==3976== Memcheck, a memory error detector ==3976== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==3976== Using Valgrind-3.7.0.SVN and LibVEX; rerun with -h for copyright info ==3976== Command: /bin/testapp ==3976== --3976-- Valgrind options: --3976-- -v --3976-- --tool=memcheck --3976-- --leak-check=yes --3976-- --workaround-gcc296-bugs=yes --3976-- --run-libc-freeres=no --3976-- --vgdb=yes --3976-- Contents of /proc/version: --3976-- Linux version 2.6.32.32 (netgear@HSDC-INA130RRK0) (gcc version 4.3.3 (GCC) ) #1 Thu Dec 1 16:55:56 IST 2011 --3976-- Arch and hwcaps: MIPS, mips-baseline --3976-- Page sizes: currently 4096, max supported 4096 --3976-- Valgrind library directory: /var/tmp/install/lib/valgrind --3976-- Reading syms from /bin/testapp (0x400000) --3976-- object doesn't have a symbol table --3976-- Reading syms from /var/tmp/install/lib/valgrind/memcheck-mips-linux (0x1000000) --3976-- object doesn't have a dynamic symbol table --3976-- Reading suppressions file: /var/tmp/install/lib/valgrind/default.supp ==3976== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-3976 ==3976== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-3976 ==3976== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-3976 ==3976== ==3976== TO CONTROL THIS PROCESS USING vgdb (which you probably ==3976== don't want to do, unless you know exactly what you're doing, ==3976== or are doing some strange experiment): ==3976== /var/tmp/install/lib/valgrind/../../bin/vgdb --pid=3976 ...command... ==3976== ==3976== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==3976== /path/to/gdb /bin/testapp ==3976== and then give GDB the following command ==3976== target remote | /var/tmp/install/lib/valgrind/../../bin/vgdb --pid=3976 ==3976== --pid is optional if only one valgrind process is running ==3976== ==3976== Conditional jump or move depends on uninitialised value(s) ==3976== at 0x40047EC: ??? (in /lib/ld-uClibc-0.9.30.1.so) ==3976== by 0x4000AE3: ??? (in /lib/ld-uClibc-0.9.30.1.so) ==3976== --3976-- Reading syms from /var/tmp/install/lib/valgrind/vgpreload_core-mips-linux.so (0x4816000) --3976-- Reading syms from /var/tmp/install/lib/valgrind/vgpreload_memcheck-mips-linux.so (0x4827000) Before calling the function After Calling the functio ==3976== ==3976== HEAP SUMMARY: ==3976== in use at exit: 0 bytes in 0 blocks ==3976== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==3976== ==3976== All heap blocks were freed -- no leaks are possible ==3976== ==3976== Use --track-origins=yes to see where uninitialised values come from ==3976== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ==3976== ==3976== 1 errors in context 1 of 1: ==3976== Conditional jump or move depends on uninitialised value(s) ==3976== at 0x40047EC: ??? (in /lib/ld-uClibc-0.9.30.1.so) ==3976== by 0x4000AE3: ??? (in /lib/ld-uClibc-0.9.30.1.so) ==3976== ==3976== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) # # # I am trying various combination of options on valgrind but with no success. Please let me know an example on how to test and application using valgrind. Or some testcase results. Please let me know if I am doing some thing wrong. -Anand Moon @Anand Moon Without knowing how you program looks like, how you compiled it, how the system you are testing it on looks like, etc, one can not get you relevant answer. However, I assume here that you compiled/linked your program statically, in which case Valgrind will not report errors for malloc. I would suggest you to read FAQ at http://valgrind.org/docs/manual/faq.html. It teaches me how to compile the MIPS version valgrind
> >
> > It need to download some patches and make some modification
> >
> > like this:
> >
> > $ svn export -r 12270 svn://svn.valgrind.org/valgrind/trunk
> > $ cd trunk
> > $ patch -p0 < ../existing_files_r12270_mips.diff
> > $ patch -p0 < ../new_files_r12270_mips_A.diff
> > $ patch -p0 < ../new_files_r12270_mips_B.diff
> > $ ./autogen.sh
> > $ ./configure
> > $ make
> > $ make install
> >
> > when I run the ./autogen.sh then it shows this error
> >
EXTRA_DIST: variable `noinst_SCRIPTS' is used but `noinst_SCRIPTS' is undefined
error: while running 'automake -a'
Can anybody tell me why did I meet this error?
@Petar Hi, I add 2 small patches of compilation : configure.patch : there is a problem in the configure file, to have the version of gcc, it s better to use gcc -dumpversion ( the method with the SED on gcc -v , is ko for me.) mips_gcc4.6.1.patch with gcc4.6.1 there is a issue on a function ASM redefined. Regards, Frédéric Created attachment 66445 [details]
gcc -dumpversion
Created attachment 66446 [details]
redefined function asm
(In reply to comment #61) > there is a problem in the configure file, to have the version of gcc, it s > better to use gcc -dumpversion ( the method with the SED on gcc -v , is ko for > me.) Does the patch checked in as r12274 on the trunk work for you ? Hi,Petar I have some question can't solve I follow the steps like $ svn export -r 11845 svn://svn.valgrind.org/valgrind/trunk $ cd trunk $ patch -p0 < ../r11845_mips.diff $ ./autogen.sh $ ./configure $ make $ make install but when I execute the step ./autogen.sh it shows the error EXTRA_DIST: variable `noinst_SCRIPTS' is used but `noinst_SCRIPTS' is undefined error: while running 'automake -a' Could you tell me where should I modify? (In reply to comment #12) > Hello everyone, > > here are the updated patches which provide MIPS/Linux support for Valgrind. > Two patches will be attached: > > 1. existing-files-changes.tar.bz2 > 2. r11845_mips.tar.bz2 > > The first patch has the changes only to the existing files, so the review can > be done more easily. > The second patch is a complete patch (it contains changes both to the existing > files and new files), and it can be applied to the revision 11845 from the main > Valgrind trunk. If you are looking to use Valgrind for MIPS, download this > patch. > > If you want to apply the patch and build Valgrind natively, here are brief > instructions: > > $ svn export -r 11845 svn://svn.valgrind.org/valgrind/trunk > $ cd trunk > $ patch -p0 < ../r11845_mips.diff > $ ./autogen.sh > $ ./configure > $ make > $ make install > > You can also use the cross-toolchain, if you prefer it. > > Additional configure options: > > ./configure --host=mipsel-linux-gnu --prefix=<path_to_install_directory> > [--with-pagesize=<4|16|64>] > > * --host=mips-linux-gnu is necessary only if Valgrind is built on platform > other then MIPS, tools for building MIPS application have to be in PATH. > > * --with-pagesize option is used to set default PAGE SIZE. If option is not > used, PAGE SIZE is set to value default for platform where Valgrind is > built. Possible values are 4, 16 of 64 and represents size in kilobytes. > > * --host=mips-linux-gnu is necessary if you compile it with cross toolchain > compiler for big endian platform. > > * --host=mipsel-linux-gnu is necessary if you compile it with cross toolchain > compiler for litle endian platform. > > * If you are compiling Valgrind with gcc version older then gcc (GCC) 4.5.1 > you must specify CFLAGS="-mips32r2 -mplt", e.g. > ./configure --prefix=<path_to_install_directory> > CFLAGS="-mips32r2 -mplt" > > > This patch is applicable for MIPS32r2 instruction set. It supports both > little-endian and big-endian cores. It has been tested with different programs > on different MIPS boards. The list of tested programs include Firefox and > QtCreator. @Frédéric > configure.patch : > there is a problem in the configure file, to have the version of gcc, it s > better to use gcc -dumpversion ( the method with the SED on gcc -v , is ko for > me.) Yes, I am aware of the issue, and Bart had a fix for it in r12274 (see his comment above). He may be aware of any obstacles if "-dumpversion" is used. > mips_gcc4.6.1.patch > with gcc4.6.1 there is a issue on a function ASM redefined. We have not tested yet with 4.6.1 based toolchain, but if it is causing a build error, your change should resolve it, thanks. @York ./autogen.sh should work without any problems. You may want to check if you have recent versions of autoconf and automake on your build system. Also, please use patches based on r12270. @Petar
Could you tell me what's the difference between the r11845 and r12270?
Because I am a rookie, I also don't know the difference between ./configure and
./configure --host=mipsel-linux-gnu --prefix=<path_to_install_directory>
[--with-pagesize=<4|16|64>]
If I only use ./configure, can I run the valgrind on the mips architecture?
Another thing is could you explain the function of gcc-dumpversion and redefined
function asm? Thank you very much
Sorry for asking stupid question I just follow the patch steps and try to type "autogen.sh" and it shows this kind of error, so is this question related the auto tool? thanks (In reply to comment #67) > @York > > ./autogen.sh should work without any problems. You may want to check if you > have recent versions of autoconf and automake on your build system. > Also, please use patches based on r12270. @Hello,Petar
I follow the cross-compile method like "./configure --host=mips-linux-gnu --with-pagesize=n" and it can successfully pass but after configure, I type "make"
and it shows this kind of error:
../include/pub_tool_basics.h:278:4: error: #error Unknown arch
In file included from ../include/pub_tool_vki.h:49,
from pub_core_vki.h:44,
from m_commandline.c:32:
../include/vki/vki-linux.h:1370:2: error: #error edit for your odd byteorder.
In file included from ../include/pub_tool_vki.h:49,
from pub_core_vki.h:44,
from m_commandline.c:32:
../include/vki/vki-linux.h:1376: warning: parameter names (without types) in function declaration
../include/vki/vki-linux.h:1376: error: field ‘VKI_PADDED’ declared as a function
make[3]: *** [libcoregrind_mips32_linux_a-m_commandline.o] Error 1
make[3]: Leaving directory `/home/mcgrady/Desktop/val_mips/coregrind'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/home/mcgrady/Desktop/val_mips/coregrind'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/mcgrady/Desktop/val_mips'
make: *** [all] Error 2
(In reply to comment #50) > Created an attachment (id=66076) [details] > first patch to apply to r12270 for Valgrind for mips; existing files only Here are detailed comments on this patch. My main concern is that there are a number of special cases for mips32-linux in places where no other archs have a special case. A second concern is about the number of configurations you try to support. AIUI this patch tries to support big- and little-endian, with 4k, 16k and 64k page sizes. Are all of these really necessary? What is the most common configuration? Index: glibc-2.X.supp.in +##----------------------------------------------------------------------## +# Linux on mips32 Why are these necessary? Seems like there's a problem somewhere else if these are necessary. Please remove. +++ glibc-2.X-drd.supp (revision 928) +# +# Suppression patterns for MIPS32. +# Ditto +++ helgrind/Makefile.am (revision 928) +if VGCONF_ARCHS_INCLUDE_MIPS32 +mips_link_flag = -T ../valgrind_32.ld +endif + Why does mips need a linker script when none of the other targets do? This won't work with gold. Please rm. +++ VEX/priv/main_main.c (revision 928) +#if defined (_MIPSEL) + host_is_bigendian = False; +#elif defined (_MIPSEB) + host_is_bigendian = True; +#endif Is it necessary to support both big and little endian? +++ VEX/pub/libvex.h (revision 928) + + guest_mips_set_T9: + host is mips-linux ==> False + host is mips-linux ==> True + host is other ==> inapplicable Is this correct -- that the value can be validly both true or false? + + /* MIPS GUESTS only: when generating redirected code register + T9 has to be updated to shows start of the redirected function. + True => yes, False => no. */ + Bool guest_mips_set_T9; Can you explain what this means and why? Sounds like there is some bigger problem behind it. +++ VEX/auxprogs/genoffsets.c (revision 928) +#ifdef mips32 +#undef mips32 +#endif + Is this necessary? Please remove. +++ exp-bbv/Makefile.am (revision 928) +if VGCONF_ARCHS_INCLUDE_MIPS32 +mips_link_flag = -T ../valgrind_32.ld +endif + Rm this; all linker scripts must die (gold doesn't support them) +++ memcheck/tests/memalign_test.stderr.exp (revision 928) @@ -1,7 +1,7 @@ Invalid free() / delete / delete[] / realloc() at 0x........: free (vg_replace_malloc.c:...) - by 0x........: main (memalign_test.c:25) + by 0x........: main (memalign_test.c:29) Address 0x........ is 0 bytes inside a block of size 111,110 free'd at 0x........: free (vg_replace_malloc.c:...) - by 0x........: main (memalign_test.c:23) + by 0x........: main (memalign_test.c:27) Why is this necessary? +++ tests/sys_mman.h (revision 928) - assert(pagesz == 4096 || pagesz == 65536); +#if defined(VGP_mips32_linux) + assert(pagesz == 4096 || pagesz == 16384 ||pagesz == 65536); +# else + assert(pagesz == 4096 || pagesz == 65536); +# endif Just add || pagesize == 16384 to the original assert; don't ifdef. +++ memcheck/tests/memalign_test.c (revision 928) ditto re pagesize assertions +++ memcheck/tests/atomic_incs.c (revision 928) +#elif defined(VGA_mips32) + *p += n; Add a proper atomic inc +++ memcheck/mc_machine.c (revision 928) +#if defined (_MIPSEL) + tl_assert(host_is_little_endian()); +#elif defined (_MIPSEB) + tl_assert(host_is_big_endian()); +#endif This is ugly. I think the need to support more than one endianness per arch is a new requirement that the framework has never had before. Need to think of a cleaner solution. +++ memcheck/Makefile.am (revision 928) +if VGCONF_ARCHS_INCLUDE_MIPS32 +mips_link_flag = -T ../valgrind_32.ld +endif + rm + $(mips_link_flag) \ rm +++ include/vki/vki-linux.h (revision 928) +#include <config.h> why is this needed? I would prefer it was not included. +#ifdef HAVE_ARCH_SIGINFO_T typedef union vki_sigval { int sival_int; void __user *sival_ptr; @@ -452,6 +458,7 @@ } _sigpoll; } _sifields; } vki_siginfo_t; +#endif hmm, this should not be conditionally defined. +++ include/valgrind.h (revision 928) +/* addiu $15, $15, 13 + * addiu $15, $15, 29 + * addiu $15, $15, 3 + * addiu $15, $15, -45*/ This seems a bit risky (that you might come across these for real one day). Doesn't mips have rotate instructions or something more obscure, that you can use? +++ include/pub_tool_basics.h (revision 928) typedef struct { UWord _val; + UWord _valEx; Bool _isError; } SysRes; I'm concerned about this. Why does mips need two have 2 word return values for syscalls? none of the other architectures do. +++ configure.in (revision 928) +# Define MIPS_PAGE_SHIFT (--with-pagesize) Is it really necessary to support all these page sizes? It adds complexity which I prefer to avoid if necessary. +# Define HAVE_ARCH_SIGINFO_T for all except for mips As per above, why? +# Define VGCONF_HOST_IS_LITLE_ENDIAN or VGCONF_HOST_IS_BIG_ENDIAN need to support both? +++ drd/drd_bitmap.h (revision 928) +|| defined(VGA_mips32) Please indent as per house style -- || lined up with the "defined" on the line above. +++ drd/Makefile.am (revision 928) +if VGCONF_ARCHS_INCLUDE_MIPS32 + DRD_CFLAGS = \ + @FLAG_UNLIMITED_INLINE_UNIT_GROWTH@ \ + -O1 \ + @FLAG_W_EXTRA@ \ + -Wformat-nonliteral \ + -Wno-inline \ + -Wno-unused-parameter +else Why? Please remove. +++ coregrind/m_translate.c (revision 928) +# if defined(VGP_mips32_linux) + if(kind == T_Redir_Replace || kind == T_Redir_Wrap) + vex_abiinfo.guest_mips_set_T9 = True; + else + vex_abiinfo.guest_mips_set_T9 = False; +# endif You need to explain this. Why does function wrapping on mips require special handling that the other architectures do not? +++ coregrind/pub_core_trampoline.h (revision 928) +#if defined(VGP_mips32_linux) +extern Addr VG_(mips32_linux_SUBST_FOR_sigreturn); +extern Addr VG_(mips32_linux_SUBST_FOR_rt_sigreturn); +extern UInt VG_(mips32_linux_REDIR_FOR_strlen)( void* ); +extern UInt VG_(mips32_linux_REDIR_FOR_strcmp)( void*, void* ); +extern void* VG_(mips32_linux_REDIR_FOR_strchr)( void*, Int ); +#endif Are all these functions actually defined in m_trampoline.S? +++ coregrind/m_syswrap/syswrap-linux.c (revision 928) +#elif defined(VGP_mips32_linux) + { + asm volatile ( + "sw %1, %0\n\t" /* set tst->status = VgTs_Empty */ + "li $2, %2\n\t" /* set v0 = __NR_exit */ + "lw $4, %3\n\t" /* set a0 = tst->os_state.exitcode */ + "syscall\n\t" /* exit(tst->os_state.exitcode) */ + "nop" + : "=m" (tst->status) + : "r" (VgTs_Empty), "n" (__NR_exit), "m" (tst->os_state.exitcode) + : "cc", "memory" , "v0", "a0"); + } Is this correct? I don't understand mips assembly much, but it looks wrong to me. What ensures that %2 is mapped to v0 and that %3 is mapped to a0? +++ coregrind/m_syswrap/priv_types_n_macros.h (revision 928) +# elif defined(VGP_mips32_linux) + Int o_arg1; + Int o_arg2; + Int o_arg3; + Int o_arg4; + Int s_arg5; + Int s_arg6; + Int uu_arg7; + Int uu_arg8; Rm this; just use the case for x86-linux, arm-linux, etc (the first ifdef). This is current wrong for the other architectures anyway so might as well just use the current wrong code, until a proper cleanup happens (if ever). -#if defined(VGO_linux) +#if defined(VGP_mips32_linux) For the same reason, get rid of the mips32_linux special case here too. +#if (defined(VGP_mips32_linux) && defined (_MIPSEB)) + #define PSRAn_BE(n,s,t,a) \ ditto + mips v0 a0 a1 a2 a3 stack stack n/a n/a v0 (== NUM) + if (sr_isError(canonical->sres)) { + gst->guest_r2 = (Int)sr_Err(canonical->sres); + gst->guest_r7 = (Int)sr_Err(canonical->sres); + } else { What's the story on return values for syscalls? One word or two? In v0 or r2/r7? Need to have some clarity here. +++ coregrind/m_machine.c (revision 928) + (*f)(vex->guest_f1); + (*f)(vex->guest_f2); + (*f)(vex->guest_f3); apply_to_GPs_of_tid is only supposed to be used for the integer registers, so you need to rm the guest_f* cases. +++ coregrind/m_syscall.c (revision 928) need clarification re syscall return conventions, as per previous comments + if(__NR_pipe == sysno) + { + UInt *par; + *(&par) = a1; + par[0] = val; + par[1] = valHi; + } what's this for? +++ coregrind/m_transtab.c (revision 928) +#if defined(VGP_mips32_linux) +#define VKI_ICACHE (1<<0) /* flush instruction cache */ +#define VKI_DCACHE (1<<1) /* writeback and flush data cache */ +#define VKI_BCACHE (VKI_ICACHE | VKI_DCACHE) /* flush both caches */ +#endif Move these to include/vki/vki-mips32-linux.h +++ coregrind/m_initimg/initimg-linux.c (revision 928) -# ifdef ENABLE_INNER +# ifdef ENABLE_INNER || VGP_mips32_linux Rm this. If it's necessary than the problem it solves needs to be solved elsewhere. +++ coregrind/m_debugger.c (revision 928) + regs.MIPS_r14 = vex->guest_r14; + regs.MIPS_r28 = vex->guest_r28; What happened to r15 .. r27, r0, r1? +++ coregrind/m_debuglog.c (revision 928) +ULong doSyscall ( Please just do this in the same style as all the rest, instead of introducing a helper function. +++ coregrind/m_trampoline.S (revision 928) +.size VG_(mips32_linux_REDIR_FOR_strlen), .-VG_(mips32_linux_REDIR_FOR_strlen) + +/* Ditto strcmp */ +.global VG_(mips32_linux_REDIR_FOR_strcmp) +.type VG_(mips32_linux_REDIR_FOR_strcmp), @function +VG_(mips32_linux_REDIR_FOR_strcmp): + +.size VG_(mips32_linux_REDIR_FOR_strcmp), .-VG_(mips32_linux_REDIR_FOR_strcmp) + +/* Ditto index/strchr */ +.global VG_(mips32_linux_REDIR_FOR_strchr) +.type VG_(mips32_linux_REDIR_FOR_strchr), @function +VG_(mips32_linux_REDIR_FOR_strchr): + +.size VG_(mips32_linux_REDIR_FOR_strchr),.-VG_(mips32_linux_REDIR_FOR_strchr) + +.global VG_(trampoline_stuff_end) Get rid of these and the corresponding entries in the header file, since they are not being used. +++ coregrind/m_signals.c (revision 928) void VG_(synth_sigtrap)(ThreadId tid) +# if defined(VGP_mips32_linux) + /* This is for teq on mips. Teq on mips for ins: 0xXXX1f4 + * cases VKI_SIGFPE not VKI_SIGTRAP + */ + UInt *ins = (vgPlain_threads[tid].arch.vex.guest_PC-4); + UInt ins1 = (*ins) & (0x1F4); + if(ins1 == 0x1f4) + { + info.si_signo = VKI_SIGFPE; + if (VG_(clo_trace_signals)) + VG_(printf)("info.si_signo = VKI_SIGFPE; ins: 0x%x", *ins); + } +# endif This looks wrong to me. What are you trying to have happen here? IIRC the purpose of this function is to set up info and uc so it appears to the thread to which these are given (by m_sigframe) that a SIGTRAP has occurred. +++ coregrind/m_aspacemgr/aspacemgr-linux.c (revision 928) +#if defined(VGP_mips32_linux) return VG_(am_mmap_file_float_valgrind_flags) (length, prot, - VKI_MAP_FIXED|VKI_MAP_SHARED, + VKI_MAP_FIXED|VKI_MAP_PRIVATE, fd, offset ); +#else Why is it necessary to special-case mips-linux? Please rm. +++ coregrind/m_main.c (revision 928) + vg_assert(VKI_MAX_PAGE_SIZE == 4096 || VKI_MAX_PAGE_SIZE == 65536 + || VKI_MAX_PAGE_SIZE == 16384); House style: please indent so that the || is under the VKI_ above. Also, don't ifdef, just add the 16k case to the generic asertion. +# if defined(VGP_mips32_linux) + VG_(threads)[tid].arch.vex.guest_r25 = __libc_freeres_wrapper; +# endif Why is this special case necessary? +++ coregrind/pub_core_transtab_asm.h (revision 928) +#if defined(VGA_x86) || defined(VGA_amd64) || defined(VGA_mips32) This probably isn't right. It isn't harmful either, you will just lose (potentially a lot) of performance. If it is really true, with no exceptions, that mips insns are 4 byte sized and 4 byte aligned, then use the same case as ppc32 and ppc64. +++ coregrind/pub_core_aspacemgr.h (revision 928) +#elif defined(VGP_mips32_linux) +# define VG_STACK_GUARD_SZB 32768 // 2 pages Only true if you have 16k pages. Use 64k like ppc32/64 does. @Petar I install the CS toolchain, and set the path like "export PATH=/home/mcgrady/Desktop/CodeSourcery/mips-2011.03/bin:$PATH" then type the "./configure --host=mips-linux-gnu --prefix=/home/mcgrady/Desktop/val_mips_exec/ --with-pagesize=64" then execute, but it finally shows the error like this "configure: error: please use gcc >= 3.0 or clang >= 2.9" so does it mean that the version of toolchain I download is too old or has other reason? @York comment 72, I have had this issue, that s why, I added a patch "gcc -dumpversion (732 bytes, patch) " after the "./autogen.sh", you shoud patch the configure file, before launch it patch -N -p1 < ../patches/configure.patch ; Regards, Frédéric @Julian there is perhaps an issue on the linux sys wrapper, with the release 11845, I have had this bug https://bugs.kde.org/show_bug.cgi?id=283084 [Bug 283084] Kernel land variable and warning message "uninitialised value" on ioctl I don"t retry on the new version. Regards, Frédéric @Julian Thanks for the review. MIPS architecture is another architecture with its own specifics, and these uniqueness may have to be reflected at some parts of the code in which other architectures that Valgrind covers do not have anything unique. I am fully open to all advices you can give us for adapting MIPS port for Valgrind correctly. MIPS is both big-endian and little-endian. Different MIPS licensees use different endianess, and we have been getting requests for Valgrind both for LE and BE. As of page sizes, 4K, 16K, and 64K are the most common ones, and we do need to support all of these. Even a same MIPS licensee will use different page sizes for different MIPS-based products. We are aware this adds more complexity to the code, but it also gives more power and coverage to Valgrind. Your second concern in the comments is related to the linker script. Even if we set Valgrind load address to 0x3800000 there are some segments produced by MIPS linker (reginfo and interp) that are loaded on default address 0x400000 and when execution starts, Valgrind produces an error because there is memory overlapping between tested program and Valgrind. So we had to change the linker script in a way that executable segment comes first. We are also porting Gold to MIPS these days, and first patches should land soon, so we can make sure that Valgrind is successfully compiled with Gold on MIPS as well. Please advise if you believe a better approach for this issue can be found. Another concern of you are the suppression patterns. We do plan to revisit each of these, but some still widely distributed Linux distributions for MIPS trigger issues where we believe there should be none. We can deduce the number of suppressions, but this will trigger a false alarm on some common MIPS distributions. As I said, we do plan to revisit them and hopefully build a fresh Linux distribution for these and other purposes as well. Last, each of the comments you had will be addressed (we will change the assertions, make the magic sequence even more obscure, etc), and style issue will be resolved. I will also go briefly over some of your comments, as you may have some extra comment on these after I respond. > +++ exp-bbv/Makefile.am (revision 928) > +if VGCONF_ARCHS_INCLUDE_MIPS32 > +mips_link_flag = -T ../valgrind_32.ld > +endif > + > > Rm this; all linker scripts must die (gold doesn't support them) Gold actually supports linker scripts. Please advise if you think the issue can be resolved differently. > +++ memcheck/tests/memalign_test.stderr.exp (revision 928) > @@ -1,7 +1,7 @@ > Invalid free() / delete / delete[] / realloc() > at 0x........: free (vg_replace_malloc.c:...) > - by 0x........: main (memalign_test.c:25) > + by 0x........: main (memalign_test.c:29) > Address 0x........ is 0 bytes inside a block of size 111,110 free'd > at 0x........: free (vg_replace_malloc.c:...) > - by 0x........: main (memalign_test.c:23) > + by 0x........: main (memalign_test.c:27) > > Why is this necessary? Some additional assertions for different page sizes in memalign_test made this necessary. If we remove that, we can remove this one as well. > +++ include/vki/vki-linux.h (revision 928) > +#include <config.h> > why is this needed? I would prefer it was not included. > +#ifdef HAVE_ARCH_SIGINFO_T > typedef union vki_sigval { > int sival_int; > void __user *sival_ptr; > @@ -452,6 +458,7 @@ > } _sigpoll; > } _sifields; > } vki_siginfo_t; > +#endif > > hmm, this should not be conditionally defined. This is slightly different in our internal branch today. vki_siginfo has a different layout for MIPS architectures. We avoid this the way it was avoided in Linux kernel, by using #ifndef HAVE_ARCH_SIGINFO_T in the generic header before defining vki_siginfo, and letting architectures define their own siginfo in platform specific headers. So, now is #ifndef HAVE_ARCH_SIGINFO_T instead of #ifdef HAVE_ARCH_SIGINFO_T. > +++ include/pub_tool_basics.h (revision 928) > typedef > struct { > UWord _val; > + UWord _valEx; > Bool _isError; > } > SysRes; > > I'm concerned about this. Why does mips need two have 2 word > return values for syscalls? none of the other architectures do. Return values of syscall are placed in the register pair - v0 and v1. UWord _val was not sufficient to take all data. > +++ drd/Makefile.am (revision 928) > +if VGCONF_ARCHS_INCLUDE_MIPS32 > + DRD_CFLAGS = \ > + @FLAG_UNLIMITED_INLINE_UNIT_GROWTH@ \ > + -O1 \ > + @FLAG_W_EXTRA@ \ > + -Wformat-nonliteral \ > + -Wno-inline \ > + -Wno-unused-parameter > +else > > Why? Please remove. We found a gcc issue during compilation of some Valgrind files. The compiler will loop infinitely, and it is an issue related to cse, so we need to lower optimization level for this particular file (so cse related optimizations are not included). The issue is existent in newer versions of gcc as well, so if we want someone to compile Valgrind, we need to avoid the bug. The bug has been reported. > +++ coregrind/m_syswrap/syswrap-linux.c (revision 928) > +#elif defined(VGP_mips32_linux) > + { > + asm volatile ( > + "sw %1, %0\n\t" /* set tst->status = VgTs_Empty */ > + "li $2, %2\n\t" /* set v0 = __NR_exit */ > + "lw $4, %3\n\t" /* set a0 = tst->os_state.exitcode */ > + "syscall\n\t" /* exit(tst->os_state.exitcode) */ > + "nop" > + : "=m" (tst->status) > + : "r" (VgTs_Empty), "n" (__NR_exit), "m" (tst->os_state.exitcode) > + : "cc", "memory" , "v0", "a0"); > + } > > Is this correct? I don't understand mips assembly much, but it > looks wrong to me. What ensures that %2 is mapped to v0 and > that %3 is mapped to a0? Register $2 is mapped to v0 on MIPS. Register $4 is mapped to a0 on MIPS. > + if (sr_isError(canonical->sres)) { > + gst->guest_r2 = (Int)sr_Err(canonical->sres); > + gst->guest_r7 = (Int)sr_Err(canonical->sres); > + } else { > > What's the story on return values for syscalls? One word or > two? In v0 or r2/r7? Need to have some clarity here. The return values of the system calls are in v0 and v1. Information whether the system call was successfully or not is returned in register a3 (0 is success, nonzero is a failure). > +++ coregrind/m_syscall.c (revision 928) > need clarification re syscall return conventions, as per previous > comments > > + if(__NR_pipe == sysno) > + { > + UInt *par; > + *(&par) = a1; > + par[0] = val; > + par[1] = valHi; > + } > > what's this for? The pipe system call returns an array of two 32-bit file descriptors, and it uses v0 and v1. @Frédéric Thanks for anwering my question,but I still have some questions 1. I use the gcc -v dumpversion and it shows 4.4.3 2. I use the mips-linux-gnu-gcc -dumpversion and it shows 4.5.2 because I want to use the CodeSourcery toolchain to compile, so the version I should care is mips-linux-gnu-gcc -dumpversion? (this patch) "patch -N -p1 < ../patches/configure.patch" Finally, could you tell me how can I find the "patch" file you wrote on comment? I'm using the patch with GCC 3.4.6 and failed with follow error m_syscall.o `test -f 'm_syscall.c' || echo './'`m_syscall.c m_syscall.c: In function `vgPlain_do_syscall': m_syscall.c:737: warning: assignment makes pointer from integer without a cast /tmp/ccOddcaG.s: Assembler messages: /tmp/ccOddcaG.s:20: Error: illegal operands `sw $a3,($8)' make[3]: *** [libcoregrind_mips32_linux_a-m_syscall.o] Error 1 make[3]: Leaving directory `/data/workspace/valgrind-2/coregrind' make[2]: *** [all] Error 2 make[2]: Leaving directory `/data/workspace/valgrind-2/coregrind' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/data/workspace/valgrind-2' make: *** [all] Error 2 I fixed the issue by changing register name to number, but when link I get following error ld: memcheck-mips32-linux: Not enough room for program headers (allocated 4, need 5) Section to Segment mapping: Segment Sections... 00: LOPROC+0000000: .reginfo 01: LOAD: .reginfo 02: LOAD: .text .rodata 03: LOAD: .eh_frame .data.rel.ro .data .got .sbss .bss 04: STACK: Do you know how to fix it? I fixed the issue, it is because VEX version is not match with the patch, there's new package exp-dhat which didn't use ld script for linking Hello, Regarding the discussion between Petar and Julian, Are there some patches improving the performances ? Happy News Year ! Best Regards, Frédéric Created attachment 68042 [details]
changes to the existing files to provide support for Valgrind on mips
Created attachment 68043 [details]
new files to be applied on Valgrind r12270 to provide support for MIPS
Created attachment 68044 [details]
New test files to be applied on Valgrind to provide support for MIPS
Hello everyone,
here are the updated patches which provide MIPS/Linux support for Valgrind.
Three patches have just been attached:
1. changes_to_existing_files_r12270_mips.diff
2. new_mips_files_r12270.diff
3. new_mips_files_tests_r12270.diff
The first patch has the changes to the existing files only, while the second
and the third patch are new files. The third patch is related to the Valgrind
tests.
The patches should be applied against r12270 revision from the main Valgrind
trunk. If you are looking to use Valgrind for MIPS, download all patches.
If you want to apply the patch and build Valgrind natively, here are brief
instructions:
$ svn export -r 12270 svn://svn.valgrind.org/valgrind/trunk
$ cd trunk
$ patch -p0 < ../changes_to_existing_files_r12270_mips.diff
$ patch -p0 < ../new_mips_files_r12270.diff
$ patch -p0 < ../new_mips_files_tests_r12270.diff
$ ./autogen.sh
$ ./configure
$ make
$ make install
You can also use the cross-toolchain, if you prefer it.
Additional configure options:
./configure --host=mipsel-linux-gnu --prefix=<path_to_install_directory>
[--with-pagesize=<4|16|64>]
* --host=mips-linux-gnu is necessary only if Valgrind is built on platform
other then MIPS, tools for building MIPS application have to be in PATH.
* --with-pagesize option is used to set default PAGE SIZE. If option is not
used, PAGE SIZE is set to value default for platform where Valgrind is
built. Possible values are 4, 16 of 64 and represents size in kilobytes.
* --host=mips-linux-gnu is necessary if you compile it with cross toolchain
compiler for big endian platform.
* --host=mipsel-linux-gnu is necessary if you compile it with cross toolchain
compiler for little endian platform.
* If you are compiling Valgrind with gcc version older then gcc (GCC) 4.5.1
you must specify CFLAGS="-mips32r2 -mplt", e.g.
./configure --prefix=<path_to_install_directory>
CFLAGS="-mips32r2 -mplt"
* A recent version of CS toolchain, 4.5.2, also needs additional configure
option CC="mips-linux-gnu-gcc-4.5.2", e.g.
./configure --prefix=<path_to_install_directory>
CC="mips-linux-gnu-gcc-4.5.2"
This patch is applicable for MIPS32r2 instruction set. It supports both
little-endian and big-endian cores. It has been tested with different programs
on different MIPS boards. The list of tested programs include Firefox,
QtCreator, and Chromium.
Dear Petar, On the compilation of the filename : priv/guest_mips_helpers.c There is some error on the asm code. Best Regards, Frédéric mipsel-linux-uclibc-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_mips32=1 -DVGO_linux=1 -DVGP_mips32_linux=1 -DVGPV_mips32_linux_vanilla=1 -Ipriv -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -fno-builtin -Wbad-function-cast -Wcast-qual -Wcast-align -fstrict-aliasing -Wno-long-long -DBRCM_RDHWR -Wno-pointer-sign -fno-stack-protector -MT libvex_mips32_linux_a-guest_mips_helpers.o -MD -MP -MF .deps/libvex_mips32_linux_a-guest_mips_helpers.Tpo -c -o libvex_mips32_linux_a-guest_mips_helpers.o `test -f 'priv/guest_mips_helpers.c' || echo './'`priv/guest_mips_helpers.c /tmp/ccZOwJ8G.s: Assembler messages: /tmp/ccZOwJ8G.s:630: Error: opcode not supported on this processor: mips1 (mips1) `teq $14,$15,0x0' /tmp/ccZOwJ8G.s:679: Error: opcode not supported on this processor: mips1 (mips1) `teq $14,$15,0x7' /tmp/ccZOwJ8G.s:742: Error: opcode not supported on this processor: mips1 (mips1) `tne $14,$15,0x0' /tmp/ccZOwJ8G.s:791: Error: opcode not supported on this processor: mips1 (mips1) `tne $14,$15,0x7' /tmp/ccZOwJ8G.s:854: Error: opcode not supported on this processor: mips1 (mips1) `tge $14,$15,0x0' /tmp/ccZOwJ8G.s:903: Error: opcode not supported on this processor: mips1 (mips1) `tge $14,$15,0x7' /tmp/ccZOwJ8G.s:966: Error: opcode not supported on this processor: mips1 (mips1) `tlt $14,$15,0x0' /tmp/ccZOwJ8G.s:1015: Error: opcode not supported on this processor: mips1 (mips1) `tlt $14,$15,0x7' /tmp/ccZOwJ8G.s:1078: Error: opcode not supported on this processor: mips1 (mips1) `tltu $14,$15,0x0' /tmp/ccZOwJ8G.s:1127: Error: opcode not supported on this processor: mips1 (mips1) `tltu $14,$15,0x7' /tmp/ccZOwJ8G.s:1190: Error: opcode not supported on this processor: mips1 (mips1) `tgeu $14,$15,0x0' /tmp/ccZOwJ8G.s:1239: Error: opcode not supported on this processor: mips1 (mips1) `tgeu $14,$15,0x7' /tmp/ccZOwJ8G.s:1296: Error: opcode not supported on this processor: mips1 (mips1) `tge $14,$15,0x0' /tmp/ccZOwJ8G.s:1346: Error: opcode not supported on this processor: mips1 (mips1) `tge $14,$15,0x7' /tmp/ccZOwJ8G.s:1403: Error: opcode not supported on this processor: mips1 (mips1) `tgeu $14,$15,0x0' /tmp/ccZOwJ8G.s:1453: Error: opcode not supported on this processor: mips1 (mips1) `tgeu $14,$15,0x7' /tmp/ccZOwJ8G.s:1510: Error: opcode not supported on this processor: mips1 (mips1) `tlt $14,$15,0x0' /tmp/ccZOwJ8G.s:1560: Error: opcode not supported on this processor: mips1 (mips1) `tlt $14,$15,0x7' /tmp/ccZOwJ8G.s:1617: Error: opcode not supported on this processor: mips1 (mips1) `tltu $14,$15,0x0' /tmp/ccZOwJ8G.s:1667: Error: opcode not supported on this processor: mips1 (mips1) `tltu $14,$15,0x7' /tmp/ccZOwJ8G.s:1724: Error: opcode not supported on this processor: mips1 (mips1) `teq $14,$15,0x0' /tmp/ccZOwJ8G.s:1774: Error: opcode not supported on this processor: mips1 (mips1) `teq $14,$15,0x7' /tmp/ccZOwJ8G.s:1831: Error: opcode not supported on this processor: mips1 (mips1) `tne $14,$15,0x0' /tmp/ccZOwJ8G.s:1881: Error: opcode not supported on this processor: mips1 (mips1) `tne $14,$15,0x7' make[5]: *** [libvex_mips32_linux_a-guest_mips_helpers.o] Erreur 1 @Frédéric What platform are you compiling this for? Valgrind patch is applicable for mips32 CPUs. If your platform is mips32, try adding CCFLAGS="-march=mips32" to the 'configure' line. @Petar I retry in this configuration, the compilation is ok. ./configure --build=i686-pc-linux-gnu --host=mipsel-unknown-uclibc-linux -dumpmachine) --prefix=/usr CFLAGS="-DBRCM_RDHWR -march=mips32" But on real condition test : now I have a crash at the boot : ==698== valgrind: Unrecognised instruction at address 0x4efccc8. ==698== at 0x4EFCCC8: __pthread_initialize_minimal (in /lib/libpthread-0.9.32.so) ==698== by 0x5E3B6A8: __uClibc_init (in /lib/libuClibc-0.9.32.so) My "gcc_4.6.1 -v" return / it was configured in this config : --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=mipsel-unknown-linux-uclibc --enable-languages=c,c++ --disable-__cxa_atexit --enable-target-optspace --disable-libgomp --with-gnu-ld --disable-libssp --disable-multilib --enable-tls --enable-shared --enable-threads --disable-decimal-float --with-abi=32 --with-tune=mips32 My CPU is : / # cat /proc/cpuinfo system type : BCM97xxx Settop Platform build target : 7405b0 processor : 0 cpu model : BMIPS4380 V4.4 FPU V0.1 cpu MHz : 403.45 BogoMIPS : 403.45 ( udelay_val : 201728 HZ = 1000 ) wait instruction : yes microsecond timers : yes tlb_entries : 32 extra interrupt vector : yes hardware watchpoint : no ASEs implemented : mips16 VCED exceptions : not available VCEI exceptions : not available RAC setting : Unknown unaligned access : 20501 rdhwr/brdhwr traps : 85734369 / 0 Best Regards, Frédéric @Frédéric I assume it is something specific to your board. Can you put the full log of the Valgrind output as an attachment, along with 'objdump -d' of /lib/libpthread-0.9.32.so? @Petar,
Hi,
In attachment the log valgrind and the objdump result.
It seems to be this line , l 878 :
4cc8: 00604021 move t0,v1
4ccc: 00e91824 and v1,a3,t1
4cd0: 5466fffd bnel v1,a2,4cc8 <_ftext+0xd58>
Best Regards,
Frédéric
Created attachment 68435 [details] log valgrind on the release of the Comment #84 Created attachment 68436 [details]
objdump -d on the libpthread.so
Thanks for your support Frédéric @Frédéric Can you remove the flag -DBRCM_RDHWR and build Valgrind without it, and try that out? @Petar, Hello, Thank you, I retry in this config without Broadcom flag ./configure --build=i686-pc-linux-gnu --host=mipsel-unknown-uclibc-linux -dumpmachine) --prefix=/usr CFLAGS=" -march=mips32" I have no issue of compilation, and no crash at the run of valgrind, Frédéric (In reply to comment #75) To look at this more .. > Your second concern in the comments is related to the linker script. Even if we > set Valgrind load address to 0x3800000 there are some segments produced by MIPS > linker (reginfo and interp) that are loaded on default address 0x400000 and > when execution starts, Valgrind produces an error because there is memory > overlapping between tested program and Valgrind. Well, on x86_64-linux the default load address is also 0x400000 and the valgrind load address is also 0x38000000, so I suspect there's some different problem. Also, there are 935 megabytes in between 0x400000 and 0x38000000, so the executable would have to be really huge to collide with Valgrind. Can you rebuild V without the linker script, using the normal load address, 0x3800000 (note: 6 zeroes. you list only 5 above). Then attach here the output of (1) readelf -l of the test program, and (2) the output of valgrind -v -v -d -d /test/program. That might show what is going on. Created attachment 68840 [details]
readelf -l /bin/ls
@Julian
Here is the output of readelf -l /bin/ls
Created attachment 68841 [details]
valgrind -v -v -d -d /bin/ls
@Julian
Here is the output of Valgrind on MIPS if it is built without the linker script.
(In reply to comment #97) > Created an attachment (id=68841) [details] > valgrind -v -v -d -d /bin/ls Long lines on this are truncated, including the ones containing the information I need to see. Please re-send without the truncation or joining up of adjacent lines. Also, please send readelf -l for memcheck-mips32-linux. Created attachment 68857 [details]
readelf -l /bin/ls 2>&1 | tee readelf_ls.txt
@Julian
Here is the output of readelf -l /bin/ls
Hopefully this one does not appear truncated for you.
Created attachment 68858 [details]
valgrind -v -v -d -d ls 2>&1 | tee valgrind_noscripts_ls.txt
@Julian
The output of Valgrind on MIPS if it is built without the linker script.
Created attachment 68859 [details]
readelf -l memcheck-mips32-linux 2>&1 | tee readelf_memcheck.txt
@Julian
readelf output of the memcheck-mips32-linux
(In reply to comment #101) > readelf -l memcheck-mips32-linux 2>&1 | tee readelf_memcheck.txt > > Elf file type is EXEC (Executable file) > Entry point 0x380359a0 > There are 5 program headers, starting at offset 52 > > Program Headers: > Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align > REGINFO 0x0000d4 0x004000d4 0x004000d4 0x00018 0x00018 R 0x4 > LOAD 0x000000 0x00400000 0x00400000 0x000ec 0x000ec R 0x10000 > LOAD 0x010000 0x38000000 0x38000000 0x2d6d70 0x2d6d70 R E 0x10000 > LOAD 0x2e7000 0x382e7000 0x382e7000 0x096dc 0xaced90 RW 0x10000 > GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4 > > Section to Segment mapping: > Segment Sections... > 00 .reginfo > 01 .reginfo > 02 .text .rodata > 03 .eh_frame .data .got .sbss .bss > 04 What are these .reginfo sections for? Is there a command line flag to give to ld that will get rid of them? Why are they at the default load address? Is that a bug in the linker? (In reply to comment #102) @Julian .reginfo is a section that describes the registers used by the code in the object file. The kernel can use this information to decide what registers it does not need to save or which coprocessors the program uses. The section also contains a field which specifies the initial value for the gp register, based on the final location of the global data area in memory. What we can do is to modify coregrind/link_tool_exe_linux.in script, so for MIPS we move the section start of .reginfo to different address. E.g. instead of #my $cmd="$cc -static -Wl,-Ttext=$ala"; we could be adding (for MIPS) my $cmd="$cc -static -Wl,--section-start=.reginfo=$ala"; This would also possibly include adding one more input argument for the link_tool_exe_linux script (e.g. my $arch = $ARGV[2];), etc. What do you think? (In reply to comment #103) > instead of > #my $cmd="$cc -static -Wl,-Ttext=$ala"; > > we could be adding (for MIPS) > > my $cmd="$cc -static -Wl,--section-start=.reginfo=$ala"; > > This would also possibly include adding one more input argument for the > link_tool_exe_linux script (e.g. my $arch = $ARGV[2];), etc. > > What do you think? Sounds like a good solution, if it works. Certainly sounds less intrusive than having to conditionally use a linker script in each tool Makefile.am. Can you give it a try? Hi Petar,
You provide r11845_mips, this patch for mips32.
Does this patch for mips64?
Can you provide some information how to change this patch for mips64?
I want to change some code for supporting mips64 cavium octeon platform if this work is not so hard.
I download valgrind version 11845, and this patch.
./configure --host=mips64-octeon-linux-gnu
build log:
make[3]: Entering directory `/home/xux/tools/valgrind/trunk/VEX'
if mips64-octeon-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_mips=1 -DVGO_linux=1 -DVGP_mips_linux=1 -Ipriv -O2 -g -Wall -Wmissing-prototypes -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wbad-function-cast -Wcast-qual -Wcast-align -fstrict-aliasing -Wno-long-long -Wno-pointer-sign -fno-stack-protector -MT libvex_mips_linux_a-guest_mips_helpers.o -MD -MP -MF ".deps/libvex_mips_linux_a-guest_mips_helpers.Tpo" -c -o libvex_mips_linux_a-guest_mips_helpers.o `test -f 'priv/guest_mips_helpers.c' || echo './'`priv/guest_mips_helpers.c; \
then mv -f ".deps/libvex_mips_linux_a-guest_mips_helpers.Tpo" ".deps/libvex_mips_linux_a-guest_mips_helpers.Po"; else rm -f ".deps/libvex_mips_linux_a-guest_mips_helpers.Tpo"; exit 1; fi
In file included from priv/guest_mips_helpers.c:14:
../VEX/pub/libvex_basictypes.h: In function 'Ptr_to_ULong':
../VEX/pub/libvex_basictypes.h:192: warning: cast from pointer to integer of different size
../VEX/pub/libvex_basictypes.h: In function 'ULong_to_Ptr':
../VEX/pub/libvex_basictypes.h:197: warning: cast to pointer from integer of different size
/tmp/ccXfnz1b.s: Assembler messages:
/tmp/ccXfnz1b.s:364: Error: illegal operands `move'
/tmp/ccXfnz1b.s:378: Error: illegal operands `move'
/tmp/ccXfnz1b.s:392: Error: illegal operands `move'
/tmp/ccXfnz1b.s:406: Error: illegal operands `move'
/tmp/ccXfnz1b.s:420: Error: illegal operands `move'
/tmp/ccXfnz1b.s:434: Error: illegal operands `move'
/tmp/ccXfnz1b.s:448: Error: illegal operands `move'
make[3]: *** [libvex_mips_linux_a-guest_mips_helpers.o] Error 1
make[3]: Leaving directory `/home/xux/tools/valgrind/trunk/VEX'
make[2]: *** [all] Error 2
I look up mips64 cpu instructions. mips64 don't have "MOVE" this.
Table 3.7 CPU Move Instructions
Mnemonic Instruction
MFHI Move From HI Register
MFLO Move From LO Register
MOVF Move Conditional on Floating Point False
MOVN Move Conditional on Not Zero
MOVT Move Conditional on Floating Point True
MOVZ Move Conditional on Zero
MTHI Move To HI Register
MTLO Move To LO Register
RDHWR Read Hardware Register
Can you provide some information how to change this patch for mips64?
Change all build error assemble source code?
> Hello everyone,
> here are the updated patches which provide MIPS/Linux support for Valgrind.
> Two patches will be attached:
> 1. existing-files-changes.tar.bz2
> 2. r11845_mips.tar.bz2
> The first patch has the changes only to the existing files, so the review can
> be done more easily.
> The second patch is a complete patch (it contains changes both to the existing
> files and new files), and it can be applied to the revision 11845 from the main
> Valgrind trunk. If you are looking to use Valgrind for MIPS, download this
> patch.
> If you want to apply the patch and build Valgrind natively, here are brief
> instructions:
> $ svn export -r 11845 svn://svn.valgrind.org/valgrind/trunk
> $ cd trunk
> $ patch -p0 < ../r11845_mips.diff
> $ ./autogen.sh
> $ ./configure
> $ make
> $ make install
> You can also use the cross-toolchain, if you prefer it.
> Additional configure options:
> ./configure --host=mipsel-linux-gnu --prefix=<path_to_install_directory>
> [--with-pagesize=<4|16|64>]
> * --host=mips-linux-gnu is necessary only if Valgrind is built on platform
> other then MIPS, tools for building MIPS application have to be in PATH.
> * --with-pagesize option is used to set default PAGE SIZE. If option is not
> used, PAGE SIZE is set to value default for platform where Valgrind is
> built. Possible values are 4, 16 of 64 and represents size in kilobytes.
> * --host=mips-linux-gnu is necessary if you compile it with cross toolchain
> compiler for big endian platform.
> * --host=mipsel-linux-gnu is necessary if you compile it with cross toolchain
> compiler for litle endian platform.
> * If you are compiling Valgrind with gcc version older then gcc (GCC) 4.5.1
> you must specify CFLAGS="-mips32r2 -mplt", e.g.
> ./configure --prefix=<path_to_install_directory>
> CFLAGS="-mips32r2 -mplt"
> This patch is applicable for MIPS32r2 instruction set. It supports both
> little-endian and big-endian cores. It has been tested with different programs
> on different MIPS boards. The list of tested programs include Firefox and
> QtCreator.
(In reply to comment #104) > Sounds like a good solution, if it works. Certainly sounds > less intrusive than having to conditionally use a linker script > in each tool Makefile.am. Can you give it a try? @Julian Yes, it works. (In reply to comment #105) > Does this patch for mips64? > Can you provide some information how to change this patch for mips64? @xux Support for MIPS64 is not available in any of the patches yet. It will be submitted once we finish integration of MIPS32 patches. Created attachment 69538 [details]
changes to the existing files to provide support for Valgrind on MIPS
Comment on attachment 69538 [details]
changes to the existing files to provide support for Valgrind on MIPS
Applicable for r12391.
Created attachment 69539 [details]
new files to be applied on Valgrind r12391 to provide support for MIPS
Created attachment 69540 [details]
New test files to be applied on Valgrind to provide support for MIPS
Applicable for r12391.
Hello Julian, everyone else,
here are the updated patches which provide MIPS/Linux support for Valgrind.
A set of changes from previous reviews/feedback has been included in this
set. Also, the code has been rebased against r12391.
Three patches have just been attached:
1. changes_to_existing_files_r12391_mips.diff
2. new_mips_files_r12391.diff
3. new_mips_files_tests_r12391.diff
The first patch has the changes to the existing files only, while the second
and the third patch are new files. The third patch is related to the Valgrind
tests.
The patches should be applied against r12391 revision from the main Valgrind
trunk. If you are looking to use Valgrind for MIPS, download all patches.
If you want to apply the patch and build Valgrind natively, here are brief
instructions:
$ svn export svn://svn.valgrind.org/valgrind/trunk -r 12391 ./r12391
$ cd r12391
$ patch -p0 < ../changes_to_existing_files_r12391_mips.diff
$ patch -p0 < ../new_mips_files_r12391.diff
$ patch -p0 < ../new_mips_files_tests_r12391.diff
$ ./autogen.sh
$ ./configure
$ make
$ make install
You can also use the cross-toolchain, if you prefer it.
Additional configure options:
./configure --host=mipsel-linux-gnu --prefix=<path_to_install_directory>
[--with-pagesize=<4|16|64>]
* --host=mips-linux-gnu is necessary only if Valgrind is built on platform
other then MIPS, tools for building MIPS application have to be in PATH.
* --with-pagesize option is used to set default PAGE SIZE. If option is not
used, PAGE SIZE is set to value default for platform where Valgrind is
built. Possible values are 4, 16 of 64 and represents size in kilobytes.
* --host=mips-linux-gnu is necessary if you compile it with cross toolchain
compiler for big endian platform.
* --host=mipsel-linux-gnu is necessary if you compile it with cross toolchain
compiler for little endian platform.
* If you are compiling Valgrind with gcc version older then gcc (GCC) 4.5.1
you must specify CFLAGS="-mips32r2 -mplt", e.g.
./configure --prefix=<path_to_install_directory>
CFLAGS="-mips32r2 -mplt"
This patch is applicable for MIPS32r2 instruction set. It supports both
little-endian and big-endian cores.
> A set of changes from previous reviews/feedback has been included in this > set. Also, the code has been rebased against r12391. This is an improvement; thanks. Some comments: * still have extra args in VG_(am_get_advisory) and related functions. What problem do these solve? What happens if you remove the extra arguments? * visibility changes in coregrind/m_syswrap/syswrap-generic.c (removal of 'static') -- why did this happen? * coregrind/link_tool_exe_linux.in (revision 1035) +# For mips we need to use "--section-start=.reginfo=$ala" because +# "--section-start=.reginfo=$ala" will not put all the sections to the +# specificed address ($ala) +my $x=`$cc -v 2>&1 | grep Target | sed 's/Target: //g'`; +my $arch=substr($x, 0, index($x, '-')); +my $cmd; Comment correct? ("For mips we need to use X because Y ..."), but X == Y * mips32_dirtyhelper_rdhwr make this into a dirty helper which returns the required value and have IR put it in the correct register, rather than poking it into the guest state as you do: *(((UInt *) state) + (rt)) = x; depends on layout of VexGuestMIPS32State and will fail when that changes -- bug 296422 will change it * coregrind/m_syswrap/syswrap-mips32-linux.c + PRE/POST wrappers for mips/Linux-specific syscalls really all of these are mips specific? Seems a bit unlikely to me. * memcheck/tests/sigkill.stderr.exp-mips none/tests/tls.stdout.exp-BE none/tests/async-sigs.stderr.exp-mips why do we need a mips specific stderr.exp files here? > * still have extra args in VG_(am_get_advisory) and related functions. > What problem do these solve? What happens if you remove the extra > arguments? VG_(am_get_advisory) has to take additional parameters into account. Otherwise, the address that is returned will not always be applicable for mmap calls. This issue is seen when mmap is called with VKI_MAP_FIXED|VKI_MAP_SHARED, and the address returned by VG_(am_get_advisory) has not been correctly aligned. In these cases, mmap fails. This is caused by the fact that MIPS shared memory mask in kernel is dependent not only on page size, but also on dcache attributes (size of cache line and number of lines per cache set). > * visibility changes in coregrind/m_syswrap/syswrap-generic.c > (removal of 'static') -- why did this happen? This is due to the need for them to be seen inside of coregrind/m_syswrap/syswrap-mips32-linux.c. Three functions are needed inside of mips wrapper for system call NR_SYSCALL. > * coregrind/link_tool_exe_linux.in (revision 1035) > +# For mips we need to use "--section-start=.reginfo=$ala" because > +# "--section-start=.reginfo=$ala" will not put all the sections to the > +# specificed address ($ala) > +my $x=`$cc -v 2>&1 | grep Target | sed 's/Target: //g'`; > +my $arch=substr($x, 0, index($x, '-')); > +my $cmd; > Comment correct? ("For mips we need to use X because Y ..."), > but X == Y Typo in the comment. Word "not" will be removed from the comment. > * mips32_dirtyhelper_rdhwr > make this into a dirty helper which returns the required value > and have IR put it in the correct register, rather than poking > it into the guest state as you do: > *(((UInt *) state) + (rt)) = x; > depends on layout of VexGuestMIPS32State and will fail when > that changes -- bug 296422 will change it Ok. > * coregrind/m_syswrap/syswrap-mips32-linux.c > + PRE/POST wrappers for mips/Linux-specific syscalls > really all of these are mips specific? Seems a bit unlikely to me. I would debate that it is about the same size as syswrap-arm-linux.c, and we also implement 'sys_syscall' which contributes most to the size of the file. Do you think there is a better way to implement sys_syscall? > * memcheck/tests/sigkill.stderr.exp-mips > none/tests/tls.stdout.exp-BE > none/tests/async-sigs.stderr.exp-mips > why do we need a mips specific stderr.exp files here? The tests are generated by running the test executable (not under Valgrind) on the hardware. So, this is the output the binaries produce. Differences come from arch specific stuff, for instance SIGBUS has value of 10 on MIPS, and its value on x86 is 7. This value is printed to the standard output, so we need change the expected output. Or the value SIGUSR1 is 10 on x86, but on 16 on MIPS. The exception is tls.stdout.exp-BE, this file is not needed anymore, it will be removed. (In reply to comment #114) > > * still have extra args in VG_(am_get_advisory) and related functions. > > What problem do these solve? What happens if you remove the extra > > arguments? > > VG_(am_get_advisory) has to take additional parameters into account. > Otherwise, the address that is returned will not always be applicable for > mmap calls. This issue is seen when mmap is called with > VKI_MAP_FIXED|VKI_MAP_SHARED, and the address returned by > VG_(am_get_advisory) has not been correctly aligned. In these cases, mmap > fails. This is caused by the fact that MIPS shared memory mask in kernel is > dependent not only on page size, but also on dcache attributes (size of > cache line and number of lines per cache set). The reason I ask about this is, we had (what sounds like) exactly the same problem on ARM. See https://bugs.kde.org/show_bug.cgi?id=222545 comments 12 and later, and we fixed that without needing any new args to VG_(am_get_advisory) or related functions, by using the VKI_SHMLBA constant. So I am wondering if the same fix would for MIPS. This issue with shared memory alignment on MIPS is actually more similar to the ARM issue https://bugs.kde.org/show_bug.cgi?id=290974. The current issue with vgdb can be resolved without adding new logic to VG_(am_get_advisory) if we modify the code inside of VG_(am_mmap_file_float_valgrind_flags) that comes before and after the call to VG_(am_get_advisory). So, we can modify the part of the code that extends the length of the required memory, something like this: UInt sh_mem_alignment = VKI_SHMLBA; #if defined(VGA_mips32) if (((flags & VKI_MAP_FIXED) && (flags & VKI_MAP_SHARED)) && ((advised - (offset << VKI_PAGE_SHIFT)) & (SHM_ALIGNMENT-1))) sh_mem_alignment = SHM_ALIGNMENT; #endif if ((sh_mem_alignment > VKI_PAGE_SIZE) && (VKI_MAP_SHARED & flags)) { /* arm-linux only. See ML_(generic_PRE_sys_shmat) and bug 290974 */ req.len = length + sh_mem_alignment - VKI_PAGE_SIZE; } else { req.len = length; } advised = VG_(am_get_advisory)( &req, True/*client*/, &ok, flags, offset ); if (!ok) return VG_(mk_SysRes_Error)( VKI_EINVAL ); if ((sh_mem_alignment > VKI_PAGE_SIZE) && (VKI_MAP_SHARED & flags)) advised = VG_ROUNDUP(advised, sh_mem_alignment); Would that be better? This would resolve the issue, but VG_(am_get_advisory) may still be returning inadequate addresses when called from other places. Created attachment 70705 [details]
changes to the existing files to provide support for Valgrind on MIPS
To be applied against r12509 revision from the main Valgrind trunk and VEX r2287.
Created attachment 70706 [details]
New files to be applied to Valgrind to provide support for MIPS
To be applied against r12509 revision from the main Valgrind trunk and VEX r2287.
Created attachment 70707 [details]
New test files (memcheck/none) for Valgrind on MIPS
To be applied against r12509 revision from the main Valgrind trunk and VEX r2287.
Created attachment 70708 [details]
New test files (helgrind) for Valgrind on MIPS
To be applied against r12509 revision from the main Valgrind trunk and VEX r2287.
Hello everyone,
here are the updated patches which provide MIPS/Linux support for Valgrind.
A set of changes from previous reviews/feedback has been included in this
set. These include:
- dirty helpers for rdhwr have been removed,
- different fix for VG_(am_get_advisory) and shared memory issue has been
applied (similar to what has been done for ARM previously),
- get_inst_offset_in_function has been added to debuginfo.c to help stack
unwinding when CFI-based unwinding fails,
- comments in the code have been updated/corrected,
- added mips-specific parts of some Memcheck and Helgrind tests,
- additional test output files addded for Helgrind,
- unnecessary mips-specific test output file for BE has been removed.
Also, the code has been rebased against r12509.
Four patches have just been attached:
1. changes_to_existing_files_r12509_r2287.diff
2. new_files_r12509_r2287.diff
3. new_test_files_r12509_r2287_memcheck_none.diff
4. new_test_files_r12509_r2287_helgrind.diff
The first patch has the changes to the existing files only, while the other are
new files. The third and the forth patch are related to the Valgrind tests.
The patches should be applied against r12509 revision from the main Valgrind
trunk and VEX r2287. If you are looking to use Valgrind for MIPS, download all
patches.
If you want to apply the patch and build Valgrind natively, here are brief
instructions:
$ svn co -r12509 svn://svn.valgrind.org/valgrind/trunk
$ cd trunk/VEX
$ svn up -r2287
$ cd ..
$ patch -p0 < ../changes_to_existing_files_r12509_r2287_mips.diff
$ patch -p0 < ../new_files_r12509_r2287.diff
$ patch -p0 < ../new_test_files_r12509_r2287_memcheck_none.diff
$ patch -p0 < ../new_test_files_r12509_r2287_helgrind.diff
$ ./autogen.sh
$ ./configure
$ make
$ make install
You can also use the cross-toolchain, if you prefer it.
Additional configure options:
./configure --host=mipsel-linux-gnu --prefix=<path_to_install_directory>
[--with-pagesize=<4|16|64>]
* --host=mips-linux-gnu is necessary only if Valgrind is built on platform
other then MIPS, tools for building MIPS application have to be in PATH.
* --with-pagesize option is used to set default PAGE SIZE. If option is not
used, PAGE SIZE is set to value default for platform where Valgrind is
built. Possible values are 4, 16 of 64 and represents size in kilobytes.
* --host=mips-linux-gnu is necessary if you compile it with cross toolchain
compiler for big endian platform.
* --host=mipsel-linux-gnu is necessary if you compile it with cross toolchain
compiler for little endian platform.
* If you are compiling Valgrind with gcc version older then gcc (GCC) 4.5.1
you must specify CFLAGS="-mips32r2 -mplt", e.g.
./configure --prefix=<path_to_install_directory>
CFLAGS="-mips32r2 -mplt"
This patch is applicable for MIPS32r2 instruction set. It supports both
little-endian and big-endian cores.
Thanks for the updates. Good that you cleaned up the aspacem stuff, so AFAICS the arm-linux solution works now. Not convinced that we need new .stderr.exp for the Helgrind tests nor for origin6, but that can be investigated / fixed up post-merge. Maybe some kind of stack unwind problem? Do you have a version of these that are suitable for current trunk, that is, post tchain merge (XDirect, XIndir, XAssisted, etc al) ? Dear Petar / Julian, Info of none regression, I am trying your latest release in x86 , with massif, on the normal exit, I have the following message, and no massif.out file. I don't know yet if it s linked to my prog , to the valgrind or to the patch mips. --3347-- VALGRIND INTERNAL ERROR: Valgrind received a signal 11 (SIGSEGV) - exiting --3347-- si_code=1; Faulting address: 0x70DC0C96; sp: 0x661b80f8 valgrind: the 'impossible' happened: Killed by fatal signal ==3347== at 0x380148AD: vgPlain_arena_free (m_mallocfree.c:285) ==3347== by 0x3804DCD9: vgPlain_cli_free (replacemalloc_core.c:92) ==3347== by 0x380502FF: vgPlain_scheduler (scheduler.c:1468) ==3347== by 0x380109D6: final_tidyup (m_main.c:2478) ==3347== by 0x380112E0: shutdown_actions_NORETURN (m_main.c:2263) ==3347== by 0x380627CB: run_a_thread_NORETURN (syswrap-linux.c:178) ==3347== by 0x38062983: vgModuleLocal_start_thread_NORETURN (syswrap-linux.c:280) ==3347== by 0x380821E8: ??? (in /usr/lib/valgrind/massif-x86-linux) sched status: running_tid=23 Thread 23: status = VgTs_Runnable ==3347== at 0x4023E38: free (vg_replace_malloc.c:427) ==3347== by 0x443F933: free_mem (in /lib/libc-2.12.1.so) ==3347== by 0x443F439: __libc_freeres (in /lib/libc-2.12.1.so) ==3347== by 0x40203AF: _vgnU_freeres (vg_preloaded.c:61) ==3347== by 0x42E5652: pthread_cond_timedwait@@GLIBC_2.3.2 (in /lib/libpthread-2.12.1.so) ==3347== by 0x22355ACF: ??? Best Regards, Frédéric Reproduce without the mips patches. env : native r12509 up to r2287 Created attachment 71197 [details]
changes_to_existing_files_r12551_r2319_mips.diff
To be applied against r12551/r2319.
Created attachment 71198 [details]
new_files_r12551_r2319.diff
To be applied against r12551/r2319.
Created attachment 71199 [details]
new_test_files_r12551_r2319_memcheck_none.diff
To be applied against r12551/r2319.
Created attachment 71200 [details]
new_test_files_r12551_r2319_helgrind.diff
To be applied against r12551/r2319.
@Julian, I have just updated the patches, so they include the t-chain changes for MIPS. @Everyone The patches should be applied against r12551 revision from the main Valgrind trunk and VEX r2319. If you are looking to use Valgrind for MIPS, download all the patches. If you want to apply the patch and build Valgrind natively, here are brief instructions: $ svn co -r12551 svn://svn.valgrind.org/valgrind/trunk $ cd trunk/VEX $ svn up -r2319 $ cd .. $ patch -p0 < ../changes_to_existing_files_r12551_r2319_mips.diff $ patch -p0 < ../new_files_r12551_r2319.diff $ patch -p0 < ../new_test_files_r12551_r2319_memcheck_none.diff $ patch -p0 < ../new_test_files_r12551_r2319_helgrind.diff $ ./autogen.sh $ ./configure $ make $ make install See the comment #121 for more instructions. Created attachment 71465 [details]
changes_to_existing_files_r12592_r2360_mips.diff
To be applied against r12592/r2360.
Created attachment 71466 [details]
new_files_r12592_r2360.diff
To be applied against r12592/r2360.
Created attachment 71467 [details]
new_test_files_r12592_r2360_memcheck_none.diff
To be applied against r12592/r2360.
Created attachment 71468 [details]
new_test_files_r12592_r2360_helgrind.diff
To be applied against r12592/r2360.
A new set of patches has been attached to this page. The patches should be applied against r12592 revision from the main Valgrind trunk and VEX r2360. If you are looking to use Valgrind for MIPS, download all the patches. If you want to apply the patch and build Valgrind natively, here are brief instructions: $ svn co -r12592 svn://svn.valgrind.org/valgrind/trunk $ cd trunk/VEX $ svn up -r2360 $ cd .. $ patch -p0 < ../changes_to_existing_files_r12592_r2360_mips.diff $ patch -p0 < ../new_files_r12592_r2360.diff $ patch -p0 < ../new_test_files_r12592_r2360_memcheck_none.diff $ patch -p0 < ../new_test_files_r12592_r2360_helgrind.diff $ ./autogen.sh $ ./configure $ make $ make install See the comment #121 for more instructions. Apart from the code being rebased to these revisions, it also includes a nicer handling of system call sys_syscall and a fix for recent bug with incorrect pc address output in the stack trace (thanks to Phillipe W. for the remarks). Hi, First of all, thanks for a great port, was looking for this for a while now :). I am trying to use the patches on r12592. I am using gcc 4.3.3 with code sourcery enhancements, uclibc 0.9.30.1, binutils 2.19.1, kernel 2.6.32.42 Compilation goes well but i face some problems runtime, mainly due to libdl (?). Any hints are greatly appreciated. I paste the complete log here for a sample command of "ls" ( the _dl_get_ready_to_run prints are because i enabled LD_DEBUG feature in uclibc compilation): root@(none):~# /valgrind-install/bin/valgrind --leak-check=summary --tool=memche ck -v ls _dl_get_ready_to_run:171: Cool, ldso survived making function calls _dl_malloc:921: mmapping more memory _dl_get_ready_to_run:355: Lib Loader: (0x2aaa8000) /lib/ld-uClibc.so.0 _dl_get_ready_to_run:293: calling mprotect on the application program _dl_get_ready_to_run:621: Loading: (0x2aac5000) /lib/libgcc_s.so.1 _dl_get_ready_to_run:621: Loading: (0x2aae2000) /lib/libc.so.0 _dl_get_ready_to_run:748: Beginning relocation fixups ==487== Memcheck, a memory error detector ==487== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al. ==487== Using Valgrind-3.8.0.SVN and LibVEX; rerun with -h for copyright info ==487== Command: ls ==487== --487-- Valgrind options: --487-- --leak-check=summary --487-- --tool=memcheck --487-- -v --487-- Contents of /proc/version: --487-- Linux version 2.6.32.42 (balabhad@blrrsa0011) (gcc version 4.3.3 (GCC) ) #2 Mon Jun 4 11:43:21 IST 2012 --487-- Arch and hwcaps: MIPS32, MIPS-baseline --487-- Page sizes: currently 4096, max supported 4096 --487-- Valgrind library directory: /valgrind-install/lib/valgrind/ --487-- Reading syms from /lib/ld-uClibc-0.9.30.1.so (0x4000000) --487-- Reading syms from /rom/valgrind-install/lib/valgrind/memcheck-mips32-linux (0x38000000) --487-- object doesn't have a dynamic symbol table --487-- Scheduler: using generic scheduler lock implementation. --487-- Reading suppressions file: /valgrind-install/lib/valgrind//default.supp ==487== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-487-by-root-on-??? ==487== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-487-by-root-on-??? ==487== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-487-by-root-on-??? ==487== ==487== TO CONTROL THIS PROCESS USING vgdb (which you probably ==487== don't want to do, unless you know exactly what you're doing, ==487== or are doing some strange experiment): ==487== /valgrind-install/lib/valgrind//../../bin/vgdb --pid=487 ...command... ==487== ==487== TO DEBUG THIS PROCESS USING GDB: start GDB like this ==487== /path/to/gdb ls ==487== and then give GDB the following command ==487== target remote | /valgrind-install/lib/valgrind//../../bin/vgdb --pid=487 ==487== --pid is optional if only one valgrind process is running ==487== ==487== ==487== Process terminating with default action of signal 11 (SIGSEGV) ==487== Access not within mapped region at address 0x5554 ==487== at 0x4002078: ??? (dl-startup.c:148) ==487== by 0x4001F7C: _start (elfinterp.c:321) ==487== If you believe this happened as a result of a stack ==487== overflow in your program's main thread (unlikely but ==487== possible), you can try to increase the size of the ==487== main thread stack using the --main-stacksize= flag. ==487== The main thread stack size used in this run was 8388608. valgrind: m_scheduler/scheduler.c:923 (run_thread_for_a_while): Assertion 'two_words[0] == 0 && two_words[1] == 0' failed. ==487== at 0x380364E4: report_and_quit (m_libcassert.c:235) ==487== by 0x380366E0: vgPlain_assert_fail (m_libcassert.c:309) ==487== by 0x3808056C: run_thread_for_a_while (scheduler.c:923) ==487== by 0x38081A74: vgPlain_scheduler (scheduler.c:1254) ==487== by 0x380B41B4: run_a_thread_NORETURN (syswrap-linux.c:102) ==487== by 0x380B45AC: vgPlain_main_thread_wrapper_NORETURN (syswrap-linux.c:394) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==487== at 0x4002078: ??? (dl-startup.c:148) ==487== by 0x4001F7C: _start (elfinterp.c:321) I have been trying to run valgrind on a MIPS machine. I successfully cross compiled valgrind and ran a few test from the test suite. But whenever valgrind tries to create a coredump, an assertion fails. Its from the file coredump-elf.c vg_assert(sizeof(*regs) == sizeof(prs->pr_reg)); well apparently this assertion checks if the size of the byte array is same as the struct of registers made by the valgrind. But i am not able to get past this error. I am using valgrind on MIPS 32 machine. Note: I have done a bit of debugging and find that Struct vki_pt_regs in vki-mips32-linux.h is 8 byte alligned and with VKI_ELF_NGREG defined as 45,which will be total 180 bytes and hence the struct size cannot be equal as it is not divisible by 8. @kalyan Can you give us a little bit more information about the platform you are trying to run Valgrind on? Can you provide config.log for Valgrind? Also, what is the output to 'cat proc/cpuinfo'? Do you see the same problem with other programs? Can you try 'hello world' and see if it works? If "hello world" fails, can you try to compile it statically and run it under Valgrind? Does it fail in that case, and if so, can you attach the binary? Hi Peter,
I am trying to one of our SoCs based MIPS34 Kc.
Yes, it fails with same output with other programs also. Fails with hello world too when the program is using shared libs. I got different output if hello-world is compiled statically.
All the information, logs, binaries are embedded in valgrind-info.tar.bz2.
Please let me know if you need more info.
I have made one code change though since the compilation was failing in my environment. I defined nlist strcuture in "coregrind/m_debuginfo/readstabs.c" ( because it could not find linux/a.out.h) from one of the posts which i got while i was googling:
struct nlist
{
union
{
char *n_name;
struct nlist *n_next;
long n_strx;
} n_un;
unsigned char n_type;
char n_other;
short n_desc;
unsigned long n_value;
};
Regards
Kalyan
Created attachment 71575 [details]
contains logs, binaries for failure test case
The attachment name is actually valgrind-info-mips.7z. Apologies for confusion Created attachment 71576 [details]
coredump-elf-mips-fix.diff
Test change for coredump-elf.c
(In reply to comment #136) > I have been trying to run valgrind on a MIPS machine. I successfully cross > compiled valgrind and ran a few test from the test suite. But whenever > valgrind tries to create a coredump, an assertion fails. Its from the file > coredump-elf.c > > vg_assert(sizeof(*regs) == sizeof(prs->pr_reg)); > > well apparently this assertion checks if the size of the byte array is same > as the struct of registers made by the valgrind. > > But i am not able to get past this error. > > I am using valgrind on MIPS 32 machine. > > Note: I have done a bit of debugging and find that Struct vki_pt_regs in > vki-mips32-linux.h is 8 byte alligned and with VKI_ELF_NGREG defined as > 45,which will be total 180 bytes and hence the struct size cannot be equal > as it is not divisible by 8. @argha sen Can you try to apply the patch attached in comment #c141? What error do you get with that patch? Also, can you provide more information about the platform? Give us output for 'cat proc/cpuinfo', and 'uname -a'. Also, provide config.log, and the command line how you run Valgrind. (In reply to comment #137) @Peter Any hints from the logs i have sent out (comments 138,139,140) ? Thanks in advance for your help. > @kalyan > > Can you give us a little bit more information about the platform you are > trying to run Valgrind on? > Can you provide config.log for Valgrind? > Also, what is the output to 'cat proc/cpuinfo'? > > Do you see the same problem with other programs? Can you try 'hello world' > and see if it works? If "hello world" fails, can you try to compile it > statically and run it under Valgrind? Does it fail in that case, and if so, > can you attach the binary? @ Petar Jovanovic Just Thanks for all this development on MIPS ! (In reply to comment #143) > (In reply to comment #137) > @Peter > Any hints from the logs i have sent out (comments 138,139,140) ? > Thanks in advance for your help. @kalyan This may be something specific to your toolchain and the platform. I can confirm you that Valgrind has just been tested on 34Kc board, and it works correctly. The toolchain came from CodeSourcery which does not use uclibc like the one you have. Nevertheless, Valgrind on 34Kc can run the static binary you provided without problems, so it is something very specific to your platform or/and your rootfs. (In reply to comment #145) @Peter, Hmm, i also tried on MIPS malta 34Kc board. I get same result. Did you use any extra flags for 34kc board? I have tried so far code sourcery, normal gcc. Therefore i am wondering if the way i am compiling valgrind with my toolchain is causing problems.Have tried many combinations. Yet to try gcc > 4.5 though. Would it be possible for you to send across statically compiled valgrind binary? This would help me narrow down my problem. > (In reply to comment #143) > > (In reply to comment #137) > > @Peter > > Any hints from the logs i have sent out (comments 138,139,140) ? > > Thanks in advance for your help. > > @kalyan > This may be something specific to your toolchain and the platform. I can > confirm you that Valgrind has just been tested on 34Kc board, and it works > correctly. The toolchain came from CodeSourcery which does not use uclibc > like the one you have. Nevertheless, Valgrind on 34Kc can run the static > binary you provided without problems, so it is something very specific to > your platform or/and your rootfs. Hi Petar and others. I want to compile valgrind for router. (Broadcom BCM947xx/953xx) I made this step: ./configure --host=mipsel-linux (where mipsel-linux is from OpenWrt cross-compile toolchain) Then on make I have next error: make[3]: Entering directory `/home/bohdan/workspace/p2/vg2/trunk/coregrind' mipsel-linux-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_mips32=1 -DVGO_linux=1 -DVGP_mips32_linux=1 -DVGPV_mips32_linux_vanilla=1 -I../coregrind -DVG_LIBDIR="\"/usr/local/lib/valgrind"\" -DVG_PLATFORM="\"mips32-linux\"" -mips32 -g -Wno-long-long -MT libcoregrind_mips32_linux_a-m_trampoline.o -MD -MP -MF .deps/libcoregrind_mips32_linux_a-m_trampoline.Tpo -c -o libcoregrind_mips32_linux_a-m_trampoline.o `test -f 'm_trampoline.S' || echo './'`m_trampoline.S m_trampoline.S: Assembler messages: m_trampoline.S:1040: Error: illegal operands `li $v0,(4000+119)' m_trampoline.S:1047: Error: illegal operands `li $v0,(4000+193)' m_trampoline.S:1059: Error: illegal operands `li $v0,0' m_trampoline.S:1063: Error: illegal operands `addi $v0,$v0,1' m_trampoline.S:1064: Error: illegal operands `addi $a0,$a0,1' m_trampoline.S:1066: Error: illegal operands `lbu $t0,($a0)' m_trampoline.S:1067: Error: illegal operands `bne $t0,$zero,strlen_loop' Thanks in advance for your help. I have managed to work around the assertion with your patch.Did not need the 64 bit stuff but it might help someone else hopefully. unsubscribe On 6/7/12, iamslowdeath@gmail.com <iamslowdeath@gmail.com> wrote: > https://bugs.kde.org/show_bug.cgi?id=270777 > > --- Comment #148 from iamslowdeath@gmail.com --- > I have managed to work around the assertion with your patch.Did not need the > 64 > bit stuff but it might help someone else hopefully. > > -- > You are receiving this mail because: > You are on the CC list for the bug. > hi i am using trying to use valgrind on a mips32 architecture. Thanks for the patches as they have been quite useful. But now i have a problem running my program with valgrind and i want to debug it. But for this i want to use a custom gdb server not the inbuilt vgdb. Can you suggest me how can i plugin custom gdb server in valgrind. thanks Hi Petar and others. I need your help/advice. I am using ubuntu and want to compile valgrind for router (Broadcom BCM947xx/953xx) Router is mips architecture so i came here. I made next steps: $ svn co -r12592 svn://svn.valgrind.org/valgrind/trunk $ cd trunk/VEX $ svn up -r2360 $ cd .. $ patch -p0 < ../changes_to_existing_files_r12592_r2360_mips.diff $ patch -p0 < ../new_files_r12592_r2360.diff $ patch -p0 < ../new_test_files_r12592_r2360_memcheck_none.diff $ patch -p0 < ../new_test_files_r12592_r2360_helgrind.diff $ ./autogen.sh Then i made try which is described in comment#147. After that i download CodeSourcery cross-compile mips-2011.09 I made $ ./configure --host=mips-linux-gnu --prefix=/usr and it works $ make also have no errors but when i made $ make install it gave next error: make[4]: Entering directory `/home/bohdan/workspace/p2/vg/trunk/VEX' test -z "/usr/lib/valgrind" || /bin/mkdir -p "/usr/lib/valgrind" /usr/bin/install -c -m 644 libvex-mips32-linux.a '/usr/lib/valgrind' ( cd '/usr/lib/valgrind' && mips-linux-gnu-ranlib libvex-mips32-linux.a ) /bin/bash: line 5: mips-linux-gnu-ranlib: command not found make[4]: *** [install-pkglibLIBRARIES] Error 127 make[4]: Leaving directory `/home/bohdan/workspace/p2/vg/trunk/VEX' make[3]: *** [install-am] Error 2 make[3]: Leaving directory `/home/bohdan/workspace/p2/vg/trunk/VEX' make[2]: *** [install] Error 2 make[2]: Leaving directory `/home/bohdan/workspace/p2/vg/trunk/VEX' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/home/bohdan/workspace/p2/vg/trunk' make: *** [install] Error 2 I verify and mips-linux-gnu-ranlib command is working. What can i try now? Another question: mips-linux-gnu is for big endian? and my router is little endian. Where can i obtain mipsel-linux-gnu? Thanx a lot. Sorry for stupid questions. @ Bohdan Arzhanov If you want to install your Valgrind in /usr you probably want to use sudo make install. If you want to compile V for little endian you may try CFLAGS="-EL" when you do configure. See comment 121. (In reply to comment #152) > @ Bohdan Arzhanov > > If you want to install your Valgrind in /usr you probably want to use sudo > make install. > If you want to compile V for little endian you may try CFLAGS="-EL" when you > do configure. See comment 121. Thank you for your help. Yes, it was sudo make install :) Can you give me some advice about how to solve an error during make install? (comment#151) (In reply to comment #134) > A new set of patches has been attached to this page. These patches have now been merged to the Valgrind trunk, so please check out and use that instead. Revision numbers for the merge are vex 2375 2376, valgrind 12616 12617 12618. Removing CC who requested unsubscription. I am using a shared memory program that runs fine but in the VALGRIND MIPS and it is failing the shmat. Searching on the problem had led me to https://bugs.kde.org/show_bug.cgi?id=222545 where I see it has been fixed. My problem is an replica of the above bug. It must be something to do with the MIPS port as the program runs fine under valgrind on PC. Regards, Argha Sen @Argha Sen Can you try to sync up with the latest Valgrind code from the repository (rev 12658) and see if your shmat issue can still be reproduced? (In reply to comment #156) > I am using a shared memory program that runs fine but in the VALGRIND MIPS > and it is failing the shmat. Searching on the problem had led me to > https://bugs.kde.org/show_bug.cgi?id=222545 where I see it has been fixed. > My problem is an replica of the above bug. It must be something to do with > the MIPS port as the program runs fine under valgrind on PC. > > Regards, > Argha Sen @Petar Jovanovic The shmat issue is solved on using the new svn code. FYI the svn does not have the updated coredump patch included. (In reply to comment #158) > @Petar Jovanovic > The shmat issue is solved on using the new svn code. > FYI the svn does not have the updated coredump patch included. @Argha Sen coredump issue is resolved in a different way now. Check the latest code and see if coredump works correctly for you. Created attachment 72192 [details]
The older patches are obsolete now.
Revisions 12680 and up have most of the content from the patches in. No need to use the older patches now.
Closing. Please report any problems associated with this port in new bug reports. HI , Looks like I'm facing similar issue . cc1: error: unrecognized command line option "-mips32" Just downloaded the code 3.8.1 and tried to cross compile for mips-linux. Also tried to down load the patch but could not able to , please help me with right data that i can go ahead. thanks , viswa Hi viswa, You need to configure only after applying the patches. Also you need to check your gcc compiler version. Also since you are cross-compiling check the way your gcc binary is named. Generally it will be architecture specific triplets form. can you suggest me the right path to down load the patches as mentioned . I'm missing download option when i try it from my Browser. for the sake of clarity , i could not able to down load the attachement files to down to apply the patch procedure . Thanks (In reply to comment #165) > for the sake of clarity , i could not able to down load the attachement > files to down to apply the patch procedure . > > Thanks @viswanath This issue has been closed. If you believe you have a valid Valgrind issue, open a new bug, add reproduction steps, put the details of your environment, toolchain, etc. |
Created attachment 58852 [details] changes to the existing files (patch 1) Version: 3.6 SVN (using Devel) OS: Linux Hello, here are the patches to provide MIPS/Linux support to Valgrind. You can find two patches attached to this request: 1. changes-to-existing-files 2. valgrind-mips The first patch has the changes only to the existing files, so you can review the impact on the existing files more easily. The second patch is a complete patch (it contains changes both to the existing files and new files), so you can apply it and test it. The port has been tested on Malta 74Kc board. The patches have been rebased against r11570 (25th February). Feedback is welcome. Reproducible: Always