~ # valgrind --tool=memcheck ls
==11696== Memcheck, a memory error detector
==11696== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==11696== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==11696== Command: ls
==11696== 
==11696== Invalid write of size 8
==11696==    at 0x4001C28: _dl_start_user (in /lib64/ld-2.9.so)
==11696==    by 0x4001BB8: __start (in /lib64/ld-2.9.so)
==11696==  Address 0xfff000868 is on thread 1's stack
==11696==  8 bytes below stack pointer
==11696== 
==11696== Invalid read of size 8
==11696==    at 0x41D3594: (below main) (libc-start.c:213)
==11696==  Address 0xffffffffffff8a00 is not stack'd, malloc'd or (recently) free'd
==11696== 
==11696== 
==11696== Process terminating with default action of signal 10 (SIGBUS): dumping core
==11696==    at 0x41D3594: (below main) (libc-start.c:213)

valgrind: m_coredump/coredump-elf.c:260 (fill_prstatus): Assertion 'sizeof(*regs) == sizeof(prs->pr_reg)' failed.

host stacktrace:
==11696==    at 0x3804B860: show_sched_status_wrk (m_libcassert.c:319)
==11696==    by 0x3804BBB8: report_and_quit (m_libcassert.c:390)
==11696==    by 0x3804BE44: vgPlain_assert_fail (m_libcassert.c:455)
==11696==    by 0x3807F878: fill_prstatus (coredump-elf.c:260)
==11696==    by 0x3807F878: dump_one_thread (coredump-elf.c:567)
==11696==    by 0x3807FBCC: make_elf_coredump (coredump-elf.c:670)
==11696==    by 0x3807FBCC: vgPlain_make_coredump (coredump-elf.c:742)
==11696==    by 0x38066AAC: default_action (m_signals.c:1770)
==11696==    by 0x38066AAC: deliver_signal (m_signals.c:1829)
==11696==    by 0x38068744: sync_signalhandler_from_kernel (m_signals.c:2487)
==11696==    by 0x38068744: sync_signalhandler (m_signals.c:2575)
==11696==    by 0xFFFFFFF00C: ???

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==11696==    at 0x41D3594: (below main) (libc-start.c:213)


Reproducible: Always

Steps to Reproduce:
   The signal 10 (SIGBUS): dumping core and Assertion 'sizeof(*regs) == sizeof(prs->pr_reg)' , and other programs also have the same problems. 
In https://bugs.kde.org/show_bug.cgi?id=325538, the patch for the 3.9 version provide a solution to this bug. However, this patch berings other inexplicable problems in the 3.10 version,
such as unidentified command:vex mips->IR: unhandled instruction bytes: 0xD8 0x5E 0xFE 0xF6




~ # uname -a
Linux (none) 2.6.32.13-Cavium-Octeon #1 SMP Wed Sep 3 12:55:04 CST 2014 mips64 unknown