|
From: Ivo R. <iv...@iv...> - 2014-06-01 03:18:39
|
>> 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. Thank you for confirming my suspicion. > Instead, perform the comparison only when the result can > possibly affect execution, which is at a system call. That's what I had in my sleeve provided the write interception proves unfeasible. >> ---------------------- >> 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. It is called 'schedctl' and you can find the header file here: http://src.illumos.org/source/xref/illumos-gate/usr/src/uts/common/sys/schedctl.h#70 Not much documentation is available, though. The concept is briefly touched here: https://blogs.oracle.com/dave/entry/inverted_schedctl_usage_in_the but it mainly discusses 'sc_preemptctl' flag, not 'sc_sigblock' flag. > 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. The latter - OS provides an address of sc_shared_t (after a corresponding syscall). That piece of memory is then shared between kernel and libc for a particular thread. > 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. Exactly. > 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. Will investigate. Thank you for responding, I. |