|
From: Crestez D. L. <cdl...@gm...> - 2015-03-26 13:28:25
|
Hello,
I'm attempting to run valgrind 3.10.1 from the official release on mips64 (cavium octeon2 hardware). I'm using a cavium-provided toolchain and kernel patches.
One of the issues I encountered is that anything to do with TLS fails immediately (somewhere in early glibc init). It seems that this is because the cavium-provided toolchain expects the TLS pointer in the $k0 register. Normally the k0 and k1 registers are reserved for use by the OS kernel and userspace is not supposed to do anything with it. The cavium kernel includes a patch which always sets the k0 register right before returning from any syscall. That patch is not in linux upstream and the implementation is probably not portable to non-cavium processors.
I was able to get some simple programs to run (including C++ stuff) with the following valgrind patch:
--- coregrind/m_syswrap/syswrap-main.c
+++ coregrind/m_syswrap/syswrap-main.c
@@ -1127,6 +1127,9 @@ void putSyscallStatusIntoGuestState ( /*IN*/ ThreadId tid,
gst->guest_r3 = sr_ResEx(canonical->sres);
gst->guest_r7 = (Int)sr_Err(canonical->sres);
}
+ /* HACK for cavium k0 TLS */
+ gst->guest_r26 = gst->guest_ULR;
+
VG_TRACK( post_reg_write, Vg_CoreSysCall, tid,
OFFSET_mips64_r2, sizeof(UWord) );
VG_TRACK( post_reg_write, Vg_CoreSysCall, tid,
@@ -1134,6 +1137,10 @@ void putSyscallStatusIntoGuestState ( /*IN*/ ThreadId tid,
VG_TRACK( post_reg_write, Vg_CoreSysCall, tid,
OFFSET_mips64_r7, sizeof(UWord) );
+ /* HACK for cavium k0 TLS */
+ VG_TRACK( post_reg_write, Vg_CoreSysCall, tid,
+ OFFSET_mips64_r26, sizeof(UWord) );
+
# else
# error "putSyscallStatusIntoGuestState: unknown arch"
# endif
This is clearly a hack for a non-standard ABI. However since AFAIK the mips architecture leaves k0 effectively undefined for userspace this patch shouldn't hurt any other mips users. Presumably the same thing should be done for mips32 as well.
If you think that this sort of patch is acceptable the next step would be to post a bug in the tracker, right?
More complex programs failed to link libraries found in /usr/lib. That can be fixed by applying the patch from https://bugs.kde.org/show_bug.cgi?id=341997 . Otherwise some code in ld.so behaves incorrectly (it a legit asm interpretation error). That patch is a few months old and it has not been applied. I can confirm that it does fix something for me (for whatever that's worth).
Regards,
Leonard
|