|
From: Jeremy F. <je...@go...> - 2003-10-14 17:30:11
|
Hi all,
I've checked in all my system calls rework of the last few months onto
CVS HEAD. This patch revamps the way Valgrind handles signals and
syscalls by eliminating the need to turn all blocking syscalls into
non-blocking. It does this by creating a worker task for each thread
(ProxyLWP is the term I use) which executes blocking syscalls on the
behalf of that thread. It also handles signals, since it needs to be
the same thread to get signals interrupting syscalls properly.
My intention with this change was to make Valgrind support the full
range of Posix signal behaviour. It should now handle all the strange
corners of signal handling, including the SA_SIGINFO flag, blocking
signals around a handler, and so on.
There are a couple of minor improvements which make day-to-day use
better as well:
* It now reports fatal signals rather than just quietly dying; if
the signal is a core-dumper, it also shows the stack backtrace.
* When reporting the use of a bad FD, -v also makes it show the
backtrace to the site of the bad usage (making the message
actually useful)
* Lots of other little things
My target for this patch was Linux 2.6. I've tried as hard as possible
to make Linux 2.4 work well, but there are a few deficient corners - I
suspect no real programs will encounter them (especially if they ever
worked with the previous signals/syscalls implementation). RedHat's
version of 2.4 includes a number of 2.6 changes, and so should work more
like 2.6 than 2.4.
This is a large, complex change. I've been testing it pretty
extensively, but I expect there's still some bugs in there (I found one
just before checking in). Please sync to CVS HEAD and try it out on
your favorite programs.
New command-line options:
* --signal-polltime=<time> - on 2.4, Valgrind has to poll for
pending signals to deliver them to the appropriate threads. By
default this is every 50ms.
* --lowlat-signals=no|yes - normally the thread scheduler applies
strict a round-robin policy, but if you have a thread blocking
on signals competing against lots of CPU-bound threads, it could
take a while before it gets run. This option makes the
scheduler start running the signalled thread immediately.
* --lowlat-syscalls=no|yes - this is the same as lowlat-signals,
except that it wakes the thread quickly when a syscall unblocks.
J
|