Bug 307141 - valgrind does't work in mips-linux system
Summary: valgrind does't work in mips-linux system
Status: RESOLVED FIXED
Alias: None
Product: valgrind
Classification: Developer tools
Component: general (show other bugs)
Version: 3.8.0
Platform: unspecified Linux
: NOR critical
Target Milestone: ---
Assignee: Julian Seward
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-21 08:05 UTC by progmei
Modified: 2012-10-25 11:00 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
helloworld (671.17 KB, application/octet-stream)
2012-10-15 05:28 UTC, progmei
Details

Note You need to log in before you can comment on or make changes to this bug.
Description progmei 2012-09-21 08:05:11 UTC
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
Comment 1 Tom Hughes 2012-09-21 08:21:14 UTC
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.
Comment 2 progmei 2012-09-21 08:32:18 UTC
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?
Comment 3 Tom Hughes 2012-09-21 08:37:41 UTC
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.
Comment 4 progmei 2012-09-21 10:24:35 UTC
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.
Comment 5 Olof Sivertsson 2012-09-24 20:05:19 UTC
Try Valgrind 3.8.1. It worked better for me with a very similar problem on MIPS.
Comment 6 progmei 2012-09-27 04:48:23 UTC
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.
Comment 7 progmei 2012-09-27 08:17:27 UTC
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.
Comment 8 lbblyo 2012-10-11 02:42:26 UTC
i have the some issue
toochain:mipsel-unknown-linux-gnu-
linux:2.6.29
gcc :4.3.5
glibc 2.14
Comment 9 lbblyo 2012-10-11 02:44:06 UTC
 ./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.
Comment 10 Petar Jovanovic 2012-10-12 16:49:02 UTC
@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?
Comment 11 progmei 2012-10-15 05:28:40 UTC
Created attachment 74554 [details]
helloworld
Comment 12 progmei 2012-10-15 05:34:32 UTC
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.
Comment 13 Petar Jovanovic 2012-10-17 09:11:37 UTC
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?
Comment 14 progmei 2012-10-18 03:21:55 UTC
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
Comment 15 Petar Jovanovic 2012-10-18 22:57:44 UTC
(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?
Comment 16 progmei 2012-10-19 01:54:46 UTC
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
Comment 17 Petar Jovanovic 2012-10-19 13:05:36 UTC
(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?
Comment 18 progmei 2012-10-19 15:59:03 UTC
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.
Comment 19 Petar Jovanovic 2012-10-19 17:05:05 UTC
(In reply to comment #18)
> Could you give me a link to get the cross toolchain?

https://sourcery.mentor.com/GNUToolchain/subscription3130?lite=MIPS
Comment 20 progmei 2012-10-20 04:34:22 UTC
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)
Comment 21 Petar Jovanovic 2012-10-20 11:07:28 UTC
(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?
Comment 22 progmei 2012-10-20 13:20:36 UTC
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
Comment 23 Petar Jovanovic 2012-10-20 16:04:49 UTC
(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.
Comment 24 progmei 2012-10-22 01:58:02 UTC
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?
Comment 25 Petar Jovanovic 2012-10-22 17:46:38 UTC
(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.
Comment 26 progmei 2012-10-23 03:11:51 UTC
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)
Comment 27 Dejan Jevtic 2012-10-25 08:39:34 UTC
(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).
Comment 28 progmei 2012-10-25 11:00:24 UTC
OK, I get it.
Thank you.