valgrind for WINE

Adam Gundy arg at cyberscience.com
Thu Apr 3 10:32:57 CST 2003


At 08:08 03/04/03 -0800, Alexandre Julliard wrote:
>Adam Gundy <arg at cyberscience.com> writes:
>
>> Solaris isn't an issue here - valgrind only works on linux/x86.
>
>Of course Solaris is an issue, unless you somehow make your patch take
>effect only when running under valgrind.

currently the patched wineserver returns a PID to signal when the suspended
thread is in the 'local' client process (ie the calling thread is in the same
process as the thread to be suspended).

If the thread is 'remote' then it just returns 0 (or -1 I forget) and sends the
signal itself.

There is no reason that it can't always return -1 on Solaris...

>> >Well, sending a signal to a thread from another process is standard
>> >Linux functionality, so I'd argue that valgrind should support it one
>> >way or another.
>> 
>> which surely implies that it is OK to use kill() instead of pthread_kill()
>> as a mechanism for sending signals to a thread... I assume that under NPTL
>> pthread_kill() is just a thin wrapper for kill() anyway?
>
>No, it's a wrapper for tkill(), which is the system call to send a
>signal to a thread. kill() sends it to the whole process instead.

fair enough - we can still do that in the client if asked to by the wineserver,

there is a (tiny) amount of code duplication here - but not enough to worry about.

if we are building with NPTL, then presumably WINE will be linked -lpthread, and
be calling pthread_create() etc. valgrind will replace the pthread library with
its own version - so long as we call pthread_kill() in the client, everything will work.

the whole problem is that the wineserver wants to have unique PIDs for each thread so that
it can send signals to them, and attach to them for debugging. my patch for the wineserver
means that the wineserver doesn't want to send signals for 'normal' operation within a
process - when suspending a local thread we defer the thread suspend (currently sending SIGUSR1)
back to the client.

killing a local thread could work the same way - it doesn't at the moment, but if you are
killing a thread your code is badly broken anyway.

the only remaining reason for the wineserver to want unique PIDs is ptrace() - but we can't
debug a process running under valgrind anyway!


Seeya,
 Adam
--
Real Programmers don't comment their code. If it was hard to write,
it should be hard to read, and even harder to modify.
These are all my own opinions.




More information about the wine-devel mailing list