Bug 202766 - devel/valgrind: unhandled sysarch cmd 132 (AMD64_GET_XFPUSTATE)
Summary: devel/valgrind: unhandled sysarch cmd 132 (AMD64_GET_XFPUSTATE)
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: Dmitry Sivachenko
URL:
Keywords: patch
Depends on:
Blocks:
 
Reported: 2015-08-30 06:45 UTC by Julien Nadeau
Modified: 2016-09-08 19:41 UTC (History)
4 users (show)

See Also:
koobs: merge-quarterly?


Attachments
Quick workaround (1.73 KB, patch)
2015-08-30 06:46 UTC, Julien Nadeau
no flags Details | Diff
Proposed fix (2.83 KB, patch)
2015-08-31 13:19 UTC, Julien Nadeau
koobs: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Julien Nadeau 2015-08-30 06:45:28 UTC
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.
Comment 1 Julien Nadeau 2015-08-30 06:46:06 UTC
Created attachment 160513 [details]
Quick workaround
Comment 2 Julien Nadeau 2015-08-31 07:41:56 UTC
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
Comment 3 Julien Nadeau 2015-08-31 13:19:39 UTC
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).
Comment 4 Dmitry Sivachenko freebsd_committer freebsd_triage 2015-11-13 13:35:37 UTC
I confirm this patch fixes the issue.
Thanks!
Comment 5 commit-hook freebsd_committer freebsd_triage 2015-11-13 13:36:01 UTC
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
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2015-11-13 14:00:25 UTC
Assign to committer that resolved.

@Dmitry, should this commit be merged (MFH)?
Comment 7 Kubilay Kocak freebsd_committer freebsd_triage 2015-11-13 14:00:42 UTC
Comment on attachment 160559 [details]
Proposed fix

Port is unmaintained, implicit approval
Comment 8 Dmitry Sivachenko freebsd_committer freebsd_triage 2015-11-13 14:02:19 UTC
(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.
Comment 9 commit-hook freebsd_committer freebsd_triage 2016-02-26 18:49:43 UTC
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
Comment 10 Peter da Silva 2016-09-08 19:30:52 UTC
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?
Comment 11 Peter da Silva 2016-09-08 19:41:13 UTC
(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.