mips的VALGRIND报告ld-uClibc的库存在非法写问题

由于一块MIPS板子上的用户空间程序异常CORE DUMP,定位怀疑系统的库配套混乱. 连UCLIBC都被报告存在非法写. 目前还没有解决.
问题如下:

./valgrind ls

==2111== Memcheck, a memory error detector
==2111== Copyright (C) 2002-2013, and GNU GPL’d, by Julian Seward et al.
==2111== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==2111== Command: ls
==2111==
==2111== Invalid write of size 4
==2111== at 0x4000AA0: _start (in /lib/ld-uClibc-0.9.30.1.so)
==2111== by 0x4000A4C: _start (in /lib/ld-uClibc-0.9.30.1.so)
==2111== Address 0x7e887e6c is on thread 1’s stack
==2111== 4 bytes below stack pointer
(下面其他信息,略)

百思不得其解,不知是不是我的valgrind本身在编译时没有使用正确的GCC参数?( -Wl,–dynamic-linker,$L/lib/ld-uClibc.so.0) 比如: 1$ L=/home/you/app/uclibc
2 $gcc -Wl,--dynamic-linker,$L/lib/ld-uClibc.so.0 /
3 -Wl,-rpath-link,$L/lib / 4 -nostdlib / 5 myapp.c -o myapp / 6$L/usr/lib/crt*.o /
7 -L$L/usr/lib/ /
8 -lc
然而:valgrind用LDD检测出来引用的应该是用了LD-UCLIBC了.

./ldd valgrind

    libc.so.0 => /lib/libc.so.0 (0x2aabe000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x2ab30000)
    ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)

[收集好文]
ldd 的一个安全问题 :
http://blog.csdn.net/haoel/article/details/4795024

GCC编译的背后( 预处理和编译 汇编和链接 )
http://www.cnblogs.com/hnrainll/archive/2012/07/05/2578277.html

Linux 汇编语言开发指南
http://www.ibm.com/developerworks/cn/linux/l-assembly/index.html