|
From: John R.
|
On 05/31/2014 11:58 AM, Ivo Raisr wrote: > I would like to ask what are the possibilities > of intercepting a write to a memory address > under valgrind, regardless of a tool currently used. It would be possible, but unlikely. Every store to memory would have to compare against the address. That's too slow. Instead, perform the comparison only when the result can possibly affect execution, which is at a system call. > <<snip>> > ---------------------- > Motivation is the following: Solaris contains a special > libc/kernel synchronization mechanism. Does this feature of Solaris has a name? Please tell us the name, and include a link to the documentation. > A piece of per-thread memory is shared between libc and kernel. Either the address (or an algorithm to compute it) is known in advance before each thread starts, or the thread performs a system call to learn the address that the OS has chosen. Please document. One likely possibility is that the address is a fixed offset into the thread control block, where libc and the kernel have agreed on the location and layout of that block. > It is used for various purposes, one is for 'block-all-signals' > flag. Libc prior to certain synchronization operations writes to > that memory indicating to the kernel that all signals should > be blocked. Eventually a regular syscall is invoked; > kernel detects the flag, disables all signals and clears the > flag. The problem here is that setting this flag by libc > bypasses Valgrind's signal machinery which gets confused > by the fact that all signals are disabled in kernel without > knowing it (which would be no problem should this went > through regular syscall sigprocmask & friends). The most likely way to implement such a feature in valgrind would be to have a Solaris-specific implementation of every system call that is affected by the special control word. If <stdlib.h> "read()" were affected then there would be a Solaris-specific version of "Int VG_(read)" [currently in coregrind/m_libcfile.c] which would implement the feature: test the word, call sigprocmask() if necessary, etc. It might be necessary to have a Solaris-specific implementation of EVERY system call where valgrind uses sigprocmask, if valgrind's current internal use of sigprocmask is not compatible with the semantics of the Solaris control word. |