the valgrind can not startup in mips-linux system ./valgrind/bin/valgrind ./valgrind/bin/valgrind: error while loading shared libraries: unexpected reloc type 0x7e Reproducible: Always
That message doesn't appear anywhere in the valgrind source as far as I can see, so I suspect it is coming from ld.so when it is loading the valgrind launcher process, and that something is wrong with the way your toolchain has built and linked valgrind.
I don't know what's the problem in my toolchain. But when I compile other applications. It works file. What's the special to valgrind?
Well quite a lot, but for the actual valgrind launcher tool that seems to be failing here, not a lot. It is linked pretty much normally so I am a bit surprised it is failing. You really need one of the MIPS port people though, as I know nothing about it and that is a MIPS specific relocation type.
I hope the following information maybe useful. My target env is: winpath3 network process, with MIPS 34Kc CPU Linux 2.6.29 glibc: 2.3.5 gcc: 4.7.1 When I compile the valgrind without CFLAG -mplt, the following error raised. ./valgrind/bin/valgrind ./helloworld ==474== Memcheck, a memory error detector ==474== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==474== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info ==474== Command: ./helloworld ==474== ==474== ==474== Process terminating with default action of signal 11 (SIGSEGV) ==474== Access not within mapped region at address 0x5554 ==474== at 0x4000EA0: ??? (in /lib/ld-2.3.5.so) ==474== by 0x4000940: __start (in /lib/ld-2.3.5.so) ==474== If you believe this happened as a result of a stack ==474== overflow in your program's main thread (unlikely but ==474== possible), you can try to increase the size of the ==474== main thread stack using the --main-stacksize= flag. ==474== 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. ==474== at 0x38066BB0: ??? (in /mnt/oswp1/valgrind/lib/valgrind/memcheck-mips32-linux) ==474== by 0x38066AF0: ??? (in /mnt/oswp1/valgrind/lib/valgrind/memcheck-mips32-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==474== at 0x4000EA0: ??? (in /lib/ld-2.3.5.so) ==474== by 0x4000940: __start (in /lib/ld-2.3.5.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks.
Try Valgrind 3.8.1. It worked better for me with a very similar problem on MIPS.
It also does't work with Valgrind 3.8.1. I'm not sure if my glibc(2.3.5) is too old. Does it possible that valgrind works without -mplt option? MIPS Technologies have extended the original MIPS SVR4 ABI to include support for procedure linkage tables (PLTs) and copy relocations. These extensions allow GNU/Linux executables to use a significantly more efficient code model than the one defined by the original ABI. GCC support for this code model is available via a new command-line option, -mplt. There is also a new configure-time option, --with-mips-plt, to make -mplt the default. The new code model requires support from the assembler, the linker, and the runtime C library. This support is available in binutils 2.19 and GLIBC 2.9.
I upgrade the glibc to the latest version 2.16. It seems can solve the reloc type issue. So I think valgrind need glibc 2.9 or later, but not 2.2. And now the following issue raised. I think it's a valgrind bug /mnt/oswp1 # ./valgrind/bin/valgrind ./helloworld ==336== Memcheck, a memory error detector ==336== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==336== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==336== Command: ./helloworld ==336== ==336== ==336== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==336== Access not within mapped region at address 0x5554 ==336== at 0x4004BDC: _dl_start (in /mnt/oswp1/lib/ld-2.16.so) ==336== by 0x400107C: __start (in /mnt/oswp1/lib/ld-2.16.so) ==336== If you believe this happened as a result of a stack ==336== overflow in your program's main thread (unlikely but ==336== possible), you can try to increase the size of the ==336== main thread stack using the --main-stacksize= flag. ==336== 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. ==336== at 0x3805ECD4: ??? (in /mnt/oswp1/valgrind/lib/valgrind/memcheck-mips32-linux) ==336== by 0x3805EC28: ??? (in /mnt/oswp1/valgrind/lib/valgrind/memcheck-mips32-linux) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==336== at 0x4004BDC: _dl_start (in /mnt/oswp1/lib/ld-2.16.so) ==336== by 0x400107C: __start (in /mnt/oswp1/lib/ld-2.16.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks.
i have the some issue toochain:mipsel-unknown-linux-gnu- linux:2.6.29 gcc :4.3.5 glibc 2.14
./valgrind ./test ==362== Memcheck, a memory error detector ==362== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==362== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info ==362== Command: ./test ==362== ==362== ==362== Process terminating with default action of signal 10 (SIGBUS) ==362== at 0x4000FDC: ??? (in /lib/ld-2.14.1.so) ==362== by 0x40008C0: ??? (in /lib/ld-2.14.1.so) valgrind: m_scheduler/scheduler.c:923 (run_thread_for_a_while): Assertion 'two_w ords[0] == 0 && two_words[1] == 0' failed. ==362== at 0x3803E154: report_and_quit (m_libcassert.c:235) ==362== by 0x3803E390: vgPlain_assert_fail (m_libcassert.c:309) ==362== by 0x38095F70: run_thread_for_a_while (scheduler.c:923) ==362== by 0x380978AC: vgPlain_scheduler (scheduler.c:1254) ==362== by 0x380CF638: run_a_thread_NORETURN (syswrap-linux.c:103) ==362== by 0x380CFB80: vgPlain_main_thread_wrapper_NORETURN (syswrap-linux.c: 396) sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==362== at 0x4000FDC: ??? (in /lib/ld-2.14.1.so) ==362== by 0x40008C0: ??? (in /lib/ld-2.14.1.so) Note: see also the FAQ in the source distribution. It contains workarounds to several common problems. In particular, if Valgrind aborted or crashed after identifying problems in your program, there's a good chance that fixing those problems will prevent Valgrind aborting or crashing, especially if it happened in m_mallocfree.c. If that doesn't help, please report this bug to: www.valgrind.org In the bug report, send all the above text, the valgrind version, and what OS and version you are using. Thanks.
@progmei, lbblyo I assume this happens with any program (e.g. hello-world) you try, correct? I also assume it happens with a program linked statically? If so, can you provide a binary of a simplest statically built program that invokes this issue?
Created attachment 74554 [details] helloworld
Hi Petar, You assume is correct, it happens to any program, both static and dynamic linked program. I've attached the helloworld program with strip the debug information because I'm not allowed to attach a file large than 1M.
The program you have provided works correctly with Valgrind we built from the current trunk on 34Kc board, so I guess the issue could be the way you build Valgrind. What are the command lines you use to build Valgrind? Are you building it with a cross-toolchain (if so, which one and where did you get it?) or a native toolchain?
I use the cross-toolchain to build valgrind. I use gcc 4.7.1 glibc 2.16 and binutils 2.22 to build the cross tool. The configuration of my gcc as follow. Configured with: ../gcc-4.7.1/configure --prefix=/repo/yuhuamei/mips-linux-glibc-gnu --with-sysroot=/repo/yuhuamei/mips-linux-glibc-gnu/sysroot --target=mips-linux --enable-multilib --with-ppl=/repo/yuhuamei/ppl --with-cloog=/repo/yuhuamei/cloog-ppl --with-gmp=/repo/yuhuamei/gmp --with-arch=mips32r2 --with-float=soft --enable-__cxa_atexit --with-host-libstdcxx='-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' Thread model: posix gcc version 4.7.1 (GCC) I use the follow command lines to build valgrind, and set the CFLAGS. And I also set the environment(CC, AR, AS, LD,...) to my cross gcc. export CFLAGS="-mips32r2 -mplt" ./configure --host=mips-linux-gnu --prefix=/mnt/oswp1/valgrind
(In reply to comment #14) > I use the follow command lines to build valgrind, and set the CFLAGS. And I > also set the environment(CC, AR, AS, LD,...) to my cross gcc. > export CFLAGS="-mips32r2 -mplt" > ./configure --host=mips-linux-gnu --prefix=/mnt/oswp1/valgrind @progmei Have you built the toolchain yourself or you took it from somewhere (if so, where from?)? Can you try to build Valgrind only with CFLAGS="-mips32r2"? Omit "-mplt". How much RAM memory do you available on your system?
Hi Petar, I build the toolchain by myself. I also try to build the Valgrind only with CFLAGS="-mips32r2", Omit "-mplt" The RAM memory remain on my system is 256980K. ~# cat /proc/meminfo MemTotal: 261936 kB MemFree: 256980 kB Buffers: 0 kB Cached: 1864 kB SwapCached: 0 kB Active: 840 kB Inactive: 1236 kB Active(anon): 212 kB Inactive(anon): 0 kB Active(file): 628 kB Inactive(file): 1236 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 0 kB SwapFree: 0 kB Dirty: 0 kB Writeback: 0 kB AnonPages: 236 kB Mapped: 600 kB Slab: 1740 kB SReclaimable: 492 kB SUnreclaim: 1248 kB PageTables: 52 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 130968 kB Committed_AS: 1576 kB VmallocTotal: 1048404 kB VmallocUsed: 316 kB VmallocChunk: 1048084 kB ~# cat /proc/cpuinfo system type : Wintegra WDS3 WinPath3 Development System processor : 0 cpu model : MIPS 34Kc V5.4 BogoMIPS : 372.73 wait instruction : yes microsecond timers : yes tlb_entries : 64 extra interrupt vector : yes hardware watchpoint : no ASEs implemented : mips16 dsp mt shadow register sets : 1 core : 0 VCED exceptions : not available VCEI exceptions : not available
(In reply to comment #16) > Hi Petar, > I build the toolchain by myself. Can you try to use some off-the-shelf cross toolchain, such as the one from Mentor? If it still fails, can you enable remote ssh access to your board?
Could you give me a link to get the cross toolchain? Or could you compile the Valgrind with --prefix=/mnt/oswp1/valgrind, and so I can try it? If it is necessary, I can send the Valgrind I have built.
(In reply to comment #18) > Could you give me a link to get the cross toolchain? https://sourcery.mentor.com/GNUToolchain/subscription3130?lite=MIPS
The valgrind also can not work with the mips-2012.03-63-mips-linux-gnu-i686-pc-linux-gnu. /mnt/oswp1 # ./valgrind/bin/valgrind ./helloworld ==307== Memcheck, a memory error detector ==307== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==307== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==307== Command: ./helloworld ==307== ==307== Invalid write of size 4 ==307== at 0x4001168: _dl_start_user (in /mnt/oswp1/lib/ld-2.15.so) ==307== by 0x40010FC: __start (in /mnt/oswp1/lib/ld-2.15.so) ==307== Address 0x7e864dcc is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes ==307== hello world! ==307== ==307== HEAP SUMMARY: ==307== in use at exit: 0 bytes in 0 blocks ==307== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==307== ==307== All heap blocks were freed -- no leaks are possible ==307== ==307== For counts of detected and suppressed errors, rerun with: -v ==307== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
(In reply to comment #20) > The valgrind also can not work with the > mips-2012.03-63-mips-linux-gnu-i686-pc-linux-gnu. From what I see in the log, it looks like it works correctly. Why do you say it does not work?
I see the following error report. But I think it sould not happen. And I have another question is why I use my toolchain it report SIGSEGV? Other programs works find with my toolchain. ==307== Invalid write of size 4 ==307== at 0x4001168: _dl_start_user (in /mnt/oswp1/lib/ld-2.15.so) ==307== by 0x40010FC: __start (in /mnt/oswp1/lib/ld-2.15.so) ==307== Address 0x7e864dcc is just below the stack ptr. To suppress, use: --workaround-gcc296-bugs=yes
(In reply to comment #22) > I see the following error report. But I think it sould not happen. You are wrong here, the error should be reported. Valgrind is reporting a valid error in libc. It has been fixed upstream, so if you want to have an error free report, you should update your libc. Otherwise, you can ignore it. > And I have another question is why I use my toolchain it report SIGSEGV? Other programs works find with my toolchain. Building toolchain on your own introduces some extra unknowns to this equation.
Then I hope the glibc could solve the issue in the new version, because the latest version 2.16 also has the issue. I build the toolchain by myself with gcc 4.6.3, and it also works fine. Could you try to build the valgrind with gcc 4.7(4.7.1 and 4.7.2) toolchain?
(In reply to comment #24) > Then I hope the glibc could solve the issue in the new version, because the > latest version 2.16 also has the issue. The fix will be available in 2.17. > I build the toolchain by myself with gcc 4.6.3, and it also works fine. > Could you try to build the valgrind with gcc 4.7(4.7.1 and 4.7.2) toolchain? You seem to be right about 4.7.2 version. It seems to reveal an issue not visible in previous GCC versions. I believe this issue has been fixed with the commit r13080. Checkout the trunk and let us know if it still breaks on your platform. Thank you for reporting this issue.
It works on my platform now. And I just have a question. When I test my helloworld with static link. The Valgrind report some errors. Is this the glibc issues? /mnt/oswp1 # ./valgrind/bin/valgrind ./helloworld ==429== Memcheck, a memory error detector ==429== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==429== Using Valgrind-3.9.0.SVN and LibVEX; rerun with -h for copyright info ==429== Command: ./helloworld ==429== ==429== Conditional jump or move depends on uninitialised value(s) ==429== at 0x40A4E4: strlen (strlen.c:77) ==429== by 0x436570: fillin_rpath (dl-load.c:497) ==429== by 0x439318: _dl_init_paths (dl-load.c:865) ==429== by 0x40E1F4: _dl_non_dynamic_init (dl-support.c:271) ==429== by 0x40EC68: __libc_init_first (init-first.c:82) ==429== by 0x4013FC: (below main) (libc-start.c:164) ==429== ==429== Conditional jump or move depends on uninitialised value(s) ==429== at 0x434154: write (in /mnt/oswp1/helloworld) ==429== by 0x425DC8: _IO_file_write (fileops.c:1280) ==429== by 0x425C68: new_do_write (fileops.c:538) ==429== by 0x4270B8: _IO_do_write (fileops.c:511) ==429== by 0x427314: _IO_file_overflow (fileops.c:896) ==429== by 0x428CD0: _IO_default_xsputn (genops.c:481) ==429== by 0x426CC8: _IO_file_xsputn (fileops.c:1376) ==429== by 0x41AA5C: vfprintf (vfprintf.c:1642) ==429== by 0x401F40: printf (printf.c:34) ==429== by 0x401278: main (helloworld.c:4) ==429== hello world! ==429== ==429== HEAP SUMMARY: ==429== in use at exit: 0 bytes in 0 blocks ==429== total heap usage: 0 allocs, 0 frees, 0 bytes allocated ==429== ==429== All heap blocks were freed -- no leaks are possible ==429== ==429== For counts of detected and suppressed errors, rerun with: -v ==429== Use --track-origins=yes to see where uninitialised values come from ==429== ERROR SUMMARY: 3 errors from 2 contexts (suppressed: 0 from 0)
(In reply to comment #26) > It works on my platform now. > And I just have a question. When I test my helloworld with static link. The > Valgrind report some errors. Is this the glibc issues? @progmei The problem is not in Valgrind, it's in glibc, which is not Valgrind clean. The glibc developers refused to fix these problems (because the problems are of a "don't care" nature, and fixing them costs (a few) cycles). When you link dynamically, these errors come from libc.so.6, and can be easily suppressed, which is what Valgrind does by default. But when you link statically, these errors come from your executable (which now includes code from libc.a), and so the default Valgrind suppressions don't suppress them. You could write new suppressions (see Valgrind --gen-suppressions=yes).
OK, I get it. Thank you.