On 10.2-STABLE, when running some threaded applications with valgrind, I'm seeing: ==31628== unhandled sysarch cmd 132 ==31628== Valgrind detected that your program requires ==31628== the following unimplemented functionality: ==31628== unhandled sysarch cmd ==31628== This may be because the functionality is hard to implement, ==31628== or because no reasonable program would behave this way, ==31628== or because nobody has yet needed it. In any case, let us know at ==31628== www.valgrind.org and/or try to work around the problem, if you can. ==31628== ==31628== Valgrind has to exit now. Sorry. Bye! ==31628== sched status: running_tid=1 Thread 1: status = VgTs_Runnable ==31628== at 0x715EF0A: sysarch (in /lib/libc.so.7) ==31628== by 0x7130871: __fillcontextx2 (in /lib/libc.so.7) ==31628== by 0x6EC1630: ??? (in /lib/libthr.so.3) ==31628== by 0x6EC144F: ??? (in /lib/libthr.so.3) ==31628== by 0x6EC4171: ??? (in /lib/libthr.so.3) ==31628== by 0x6EB6FFD: ??? (in /lib/libthr.so.3) ==31628== by 0x40040ED: ??? (in /libexec/ld-elf.so.1) ==31628== by 0x4002438: ??? (in /libexec/ld-elf.so.1) I don't know how valgrind should be emulating AMD64_GET_XFPUSTATE, but the attached patch can be used to work around the problem by pretending it is unimplemented.
Created attachment 160513 [details] Quick workaround
Comment on attachment 160513 [details] Quick workaround >Index: devel/valgrind/files/patch-coregrind_m_syswrap_syswrap_amd64_freebsd_c >=================================================================== >--- devel/valgrind/files/patch-coregrind_m_syswrap_syswrap_amd64_freebsd_c (revision 0) >+++ devel/valgrind/files/patch-coregrind_m_syswrap_syswrap_amd64_freebsd_c (working copy) >@@ -0,0 +1,12 @@ >+--- coregrind/m_syswrap/syswrap-amd64-freebsd.c.orig 2015-08-30 00:08:54.235669000 -0300 >++++ coregrind/m_syswrap/syswrap-amd64-freebsd.c 2015-08-30 00:18:12.597607000 -0300 >+@@ -691,6 +691,16 @@ >+ SET_STATUS_Success2( tst->arch.vex.guest_FS_ZERO, tst->arch.vex.guest_RDX ); >+ POST_MEM_WRITE( ARG2, sizeof(void *) ); >+ break; >++ case VKI_AMD64_GET_XFPUSTATE: >++ PRINT("sys_amd64_get_xfpustate ( %#lx )", ARG2); >++ PRE_REG_READ1(int, "amd64_get_xfpustate", void *, basep) >++ PRE_MEM_WRITE( "amd64_get_xfpustate(basep)", ARG2, sizeof(void *) ); >++ >++ /* "do" the syscall ourselves; the kernel never sees it */ >++ tst = VG_(get_ThreadState)(tid); >++ SET_STATUS_Success2( tst->arch.vex.guest_FPTAG[0], tst->arch.vex.guest_FPTAG[0] ); >++ POST_MEM_WRITE( ARG2, sizeof(void *) ); >++ break; >+ default: >+ VG_(message) (Vg_UserMsg, "unhandled sysarch cmd %ld", ARG1); >+ VG_(unimplemented) ("unhandled sysarch cmd"); > >Index: devel/valgrind/files/patch-include__vki__vki-freebsd.h >=================================================================== >--- devel/valgrind/files/patch-include__vki__vki-freebsd.h (revision 395557) >+++ devel/valgrind/files/patch-include__vki__vki-freebsd.h (working copy) >@@ -8,3 +8,17 @@ > #include <netinet/tcp.h> > > #define VKI_TCP_NODELAY TCP_NODELAY >+@@ -1888,11 +1889,13 @@ >+ #define VKI_I386_SET_FSBASE 8 >+ #define VKI_I386_GET_GSBASE 9 >+ #define VKI_I386_SET_GSBASE 10 >++#define VKI_I386_SET_XFPUSTATE 11 >+ >+ #define VKI_AMD64_GET_FSBASE 128 >+ #define VKI_AMD64_SET_FSBASE 129 >+ #define VKI_AMD64_GET_GSBASE 130 >+ #define VKI_AMD64_SET_GSBASE 131 >++#define VKI_AMD64_GET_XFPUSTATE 132 >+ >+ //---------------------------------------------------------------------- >+ // From sys/module.h
Created attachment 160559 [details] Proposed fix Proposed patch implements AMD64_GET_XFPUSTATE in valgrind. Compared to a native sysarch() call, emulation is not perfect. More specifically, the XMM registers, past the first 160 bytes, are not returned. However, this appears to be sufficient for libthr's purposes (getcontextx() only requests the first 129 bytes of the state).
I confirm this patch fixes the issue. Thanks!
A commit references this bug: Author: demon Date: Fri Nov 13 13:35:02 UTC 2015 New revision: 401512 URL: https://svnweb.freebsd.org/changeset/ports/401512 Log: Add a patch for "unhandled sysarch cmd 132" error. PR: 202766 Submitted by: Julien Nadeau <vedge@hypertriton.com> Changes: head/devel/valgrind/Makefile head/devel/valgrind/files/patch-coregrind-m_syswrap-syswrap-amd64-freebsd.c head/devel/valgrind/files/patch-include__vki__vki-freebsd.h
Assign to committer that resolved. @Dmitry, should this commit be merged (MFH)?
Comment on attachment 160559 [details] Proposed fix Port is unmaintained, implicit approval
(In reply to Kubilay Kocak from comment #6) > @Dmitry, should this commit be merged (MFH)? No idea, I see nothing special with this fix. I would leave it until next quarterly branch is cut.
A commit references this bug: Author: bdrewery Date: Fri Feb 26 18:49:01 UTC 2016 New revision: 409631 URL: https://svnweb.freebsd.org/changeset/ports/409631 Log: - Take back maintainership - Add a patch for "unhandled sysarch cmd 132" error. PR: 202766 Changes: head/devel/valgrind-devel/Makefile head/devel/valgrind-devel/files/patch-coregrind-m_syswrap-syswrap-amd64-freebsd.c head/devel/valgrind-devel/files/patch-include__vki__vki-freebsd.h
Using FreeBSD 10.3-RELEASE, I get the same failure mode: --39609-- REDIR: 0x59b22c0 (libc.so.7:calloc) redirected to 0x4c24530 (calloc) ==39609== unhandled sysarch cmd 132 ==39609== Valgrind detected that your program requires ==39609== the following unimplemented functionality: ==39609== unhandled sysarch cmd ==39609== This may be because the functionality is hard to implement, ==39609== or because no reasonable program would behave this way, ==39609== or because nobody has yet needed it. In any case, let us know at ==39609== www.valgrind.org and/or try to work around the problem, if you can. ==39609== ==39609== Valgrind has to exit now. Sorry. Bye! ==39609== I have run portupgrade and verified that head/devel/valgrind-devel/files/patch-coregrind-m_syswrap-syswrap-amd64-freebsd.c is in /usr/portsdevel/valgrind-devel/files and contains the Is this supposed to be fixed in FreeBSD 10.3-release?
(In reply to Peter da Silva from comment #10) Note to self, this must have been a bit of lefotver trash from a previous install of valgrind... a brutal house-by-house cleanup of obsolete valgrind rebels from /usr/local followed by a reinstallation of the legitimate government got it working. Please ignore comment 10.