Bug 197259

I suspect that this PR_SET_GS although the stack trace quoted doesn't quite match my copy of wine.

That should read ARCH_SET_FS of course. Fixing this looks like it will be tricky as it will need to signal the GS value to VEX as it currently does for FS when ARCH_SET_FS is used.

That may be as simple as setting guest_GS_0x60 in the guest state, as it currently does for guest_FS_ZERO when setting FS but Julian probably needs to look at this and work out the best way to handle it.

I have exactly this problem when running a 32-bit valgrind to debug a 32-bit wine (which itself is running a 32-bit Firefox). However, all this is running on a 64-bit host; I presume that shouldn't matter.

Created attachment 86713 [details]
Log of unsupported arch_prtctl option

The bug still exists in the development version 3.10 (2014-04-11) as the attachment shows. The operating system is Ubuntu 14.10 dev (x86_64) and Wine was compiled as x86_64 too.

I'm seeing this as well, when running the 32-bit wine unit tests under a 64-bit wine. With a 32-bit wine, it does not occur.

An example is the hlink/hlink test.

wine-1.7.19-27-gabea10f, valgrind 3.9.0, gentoo64, gcc 4.8.2.

This bug (lack of support for arch_prctl(ARCH_SET_GS, ...)) also prevents running valgrind on QEMU's linux-user binaries on x86-64 hosts:

$ valgrind --smc-check=all ./build/x86/arm-linux-user/qemu-arm ~/linaro/qemu-misc-tests/auxv-a32 
==24273== Memcheck, a memory error detector
==24273== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==24273== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==24273== Command: ./build/x86/arm-linux-user/qemu-arm /home/petmay01/linaro/qemu-misc-tests/auxv-a32
==24273== 
==24273== Warning: set address range perms: large range [0x3a04b000, 0x13104b000) (noaccess)
==24273== Warning: ignored attempt to set SIGKILL handler in sigaction();
==24273==          the SIGKILL signal is uncatchable
==24273== Warning: ignored attempt to set SIGRT32 handler in sigaction();
==24273==          the SIGRT32 signal is used internally by Valgrind

valgrind: the 'impossible' happened:
   Unsupported arch_prtctl option

host stacktrace:
==24273==    at 0x380A484F: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24273==    by 0x380A4944: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24273==    by 0x380A4B71: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24273==    by 0x380A4B9A: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24273==    by 0x3812EA08: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24273==    by 0x380F7FD0: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24273==    by 0x380F48AA: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24273==    by 0x380F5F86: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)
==24273==    by 0x38105810: ??? (in /usr/lib/valgrind/memcheck-amd64-linux)

sched status:
  running_tid=1

Thread 1: status = VgTs_Runnable
==24273==    at 0x60993D7: arch_prctl (syscall-template.S:81)
==24273==    by 0x148B07: setup_guest_base_seg (tcg-target.c:1428)
==24273==    by 0x14A685: tcg_target_qemu_prologue (tcg-target.c:2278)
==24273==    by 0x14ACC8: tcg_prologue_init (tcg.c:381)
==24273==    by 0x174ECB: main (main.c:4071)


Incidentally there's a typo in the valgrind error message: it says "prtctl" rather than "prctl".

We have the same problem on android when running x86_64 version of dex2oat.

Based on how kernel handles this call - this pretty much as simple as enabling darwin hack for %gs which is assuming that gs is always a constant - it is actually 0x6b on linux, but it should not matter.

Can you run the crashing programs with --trace-syscalls=yes
and give the trace produced by :
PRE(sys_arch_prctl)
{
   ThreadState* tst;
   PRINT( "arch_prctl ( %ld, %lx )", ARG1, ARG2 ); <<<<<<< this line

Thanks

Sure, here you go:

SYSCALL[477,1](158) arch_prctl ( 4098, 4057740 ) --> [pre-success] Success(0x0:0x0)

Created attachment 89839 [details]
test.cpp

Attached the test that reproduces the problem

this is another one... without [pre-success]:
SYSCALL[477,1](158) arch_prctl ( 4097, 601048 )

(In reply to dimitry from comment #7)
> We have the same problem on android when running x86_64 version of dex2oat.
> 
> Based on how kernel handles this call - this pretty much as simple as
> enabling darwin hack for %gs which is assuming that gs is always a constant
> - it is actually 0x6b on linux, but it should not matter.

Are you really testing on android + x86 64 bits ?
To my knowledge, that is not a supported valgrind platform.
At least, I do not find a trace of VGPV_amd64_linux_android
i.e. the equivalent of e.g. VGPV_x86_linux_android or VGPV_arm64_linux_android

We run some android binaries on host (linux workstation) as well. But speaking of android kernel - it is basically linux kernel. So the same code should work on android.

Created attachment 89841 [details]
set/get_gs hack similar to set/get_fs hack

Implement for GS a similar hack as for FS
This generalises the 0x60 hack that was done for Darwin.
FS_ZERO and GS_0x60 have been renames FS_CONST and GS_CONST,
as in fact these hacks are working with whatever value of FS/GS, as
long as these are not modified

Feedback about patch welcome (in particular, does it still compile on darwin)

Thanks

VEX/priv/guest_amd64_helpers.c:
... alwaysDefd <- is there missing ALWAYSDEFD(guest_FS_CONST)?

VEX/pub/libvex_guest_amd64.h:
Looks like the comment for 'guest_GS_CONST' needs an update..

Otherwise lgtm.

(In reply to dimitry from comment #15)
Thanks for the feedback/testing.

> VEX/priv/guest_amd64_helpers.c:
> ... alwaysDefd <- is there missing ALWAYSDEFD(guest_FS_CONST)?
The current code has a commented line that contains such an ALWAYSDEFD for FS
and GS. Not too much idea why it is like that, but I see no reason to change it.

> 
> VEX/pub/libvex_guest_amd64.h:
> Looks like the comment for 'guest_GS_CONST' needs an update..
Not too sure what was missing, I have added the hardcoded linux value.
The new comment is:
+      /* HACK to make e.g. tls on darwin work, wine on linux work, ...
+         %gs only ever seems to hold a constant value (e.g. 0x60 on darwin,
+         0x6b on linux), and so guest_GS_CONST holds the 64-bit offset
+         associated with this constant %gs value.  (A direct analogue
+         of the %fs-const hack for amd64-linux). */
+      ULong guest_GS_CONST;

Does that look ok ? Otherwise, what do you suggest ?

Thanks

looks good to me, thanks!

Fix committed as 
  VEX Committed revision 3043.
  valgrind Committed revision 14815.