|
From: Jeremy F. <je...@go...> - 2003-08-15 07:45:15
|
I've been pretty busy over the last few weeks, and I've finally got something to show for it. The large change is the rewrite of Valgrind's syscall and signal handling. This change now makes Valgrind cope consistently with blocking syscalls without having to intercept them and turn them into non-blocking syscalls. This also required that I rewrite the signal handling, which is now much more Posix compliant. Threads have their own signal masks, the right signals are masked while handlers are running, kill(getpid(), sig) is no synchronous, and a large number of minor changes which make things a lot happier. Also, SA_SIGINFO is fully implemented, as are all the other sigaction flags except for SA_RESTORER. There are even sensible default handlers for fatal signals (ie, if your program takes a SIGSEGV and there's no handler for it, Valgrind will catch it and print useful messages about what happened). In addition to the normal "run commands and see how they work", I've been using the posix test suite (http://posixtest.sf.net) to explore all the fine corners. There's still a lot of stuff which isn't compliant, mostly because Valgrind doesn't implement everything (pthread_barrier_* anyone?) rather than because it doesn't work. That said, this is all rather fresh new code, so I'd like people to test it out before we consider moving it into the mainline. The big caveat is that I've only tested it seriously with Linux 2.6 kernels, and somewhat with standard 2.4. I gather RedHat's 2.4 is somewhat different from standard 2.4 in ways which matter to Valgrind. This patch still doesn't implement clone() for application use, but it should be relatively simple to add. The main problems are 1) choosing which subset to impement, 2) getting all the clone semantics correct, and 3) choosing which version of clone to implement (it changed a lot between 2.4 and 2.6). If you're using 2.5/2.6 kernel versions, I recommend getting the absolute latest (2.6.0-test3 at the moment), because there have been a number of bugs fixed in the thread/signal area lately. All this is available at http://www.goop.org/~jeremy/valgrind/snapshots/ BTW, if anyone is interested, I've been using Bitkeeper for my Valgrind development. All my changes are available at bk://valgrind.bkbits.net/{valgrind,syscalls,fully-patched}; see http://valgrind.bkbits.net for the web interface. J |
|
From: Jeremy F. <je...@go...> - 2003-08-20 07:50:18
|
On Mon, 2003-08-18 at 09:32, Ashley Pittman wrote: > This seems to work for me using a modified Redhat based 2.4 kernel. > I've not played with the signal stuff yet but the non-blocking syscall > code does the trick nicely. Thanks for the feedback. I've been doing a number of incremental updates since the first announcement, so I'd be interested in seeing if you get any improvements or regressions. What kinds of programs have you tried it on? > > This patch still doesn't implement clone() for application use, but it > > should be relatively simple to add. The main problems are 1) choosing > > which subset to impement, 2) getting all the clone semantics correct, > > and 3) choosing which version of clone to implement (it changed a lot > > between 2.4 and 2.6). > > I had to modify valgrind slightly to ignore the clone call before I > could use it on my system but that's a relatively minor issue. Ignore in what way? Allow cloned threads to run independently of Valgrind? J |