|
From: Ivo R. <iv...@iv...> - 2014-06-02 18:20:38
|
So after some investigation I would like to continue with this thread. 2014-06-01 4:12 GMT+02:00 John Reiser <jr...@bi...>: > Instead, perform the comparison only when the result can > possibly affect execution, which is at a system call. The dark side here is that execution is affected almost immediately, affecting almost *any* system call, not just few of them. That means not just system calls issued by the client program and intercepted in m_syswrap machinery - also syscalls used internally by valgrind for its housekeeping are affected. So instead of going this murky direction I was thinking whether at least one of the following could be feasible somehow: 1) The control flag "sc_sigblock" is set from just single place in libc. It is a small static function. This means it cannot be intercepted by a simple preload. Nonetheless, valgrind instruments this function before it runs it, like all other code. What would it take to recognize this function as currently instrumented, match the corresponding instruction block against some pattern, and replace the instruction block with something more suitable for our purposes? 2) The control flag is a part of thread control block shared between kernel and libc. Address of this control block is conveyed from kernel to libc as a result of syscall. This means valgrind has the possibility to change this address to whatever it likes. Would it be possible to return some "special" address in the sense that when libc tries to access this address (+ some offset), something happens? I have in mind for example accessing non-mapped page which would result in SIGSEGV being sent to valgrind. Valgrind then does the "right" thing (TM) :-) Now handling SIGSEGV for every access would be probably too heavyweight and I guess fixup from its handling would be too complex. Perhaps there exists another mechanism which I am not aware of? I. |