If the proxyLWP for a thread got a signal just as we were sending the
syscall request to it, then we would end up running the syscall twice.
The fix is to not check the results pipe while sending the syscall request
- wait until we're in a better state for handling signals (the deadlock
the results-read was supposed to avoid cannot actually happen).
Related to that, if we're delivering a signal to a thread, and that thread
is currently waiting for a syscall to complete, make sure we collect the
syscall results before entering the signal handler (otherwise we may end
up bogusly trying to restart the syscall by moving EIP back, even though
it now points to the signal handler rather than the syscall instruction)
This change also adds an assertion to VG_(restart_syscall) to make sure
we were actually restarting a syscall and not just randomly changing EIP
(this found the problem above).
Also, make set/getitimer run in the proxyLWP context, so that they
modify/read the proxyLWP's timers rather than the schedluer LWP's timers.
Patch from Robert Walsh <rjwalsh@durables.org>. Adds some new client
requests to allow client code to print messages through Valgrind's
logging mechanism. The new requests are:
VALGRIND_PRINTF - do a normal printf (prefixed with **PID**)
VALGRIND_PRINTF_BACKTRACE - do a printf with stack trace
VALGRIND_INTERNAL_PRINTF - printf, but for internal use (prefixed with ==PID==)
VALGRIND_INTERNAL_PRINTF_BACKTRACE - as above, with backtrace
Increased the skin major version number, to reflect the changed return values
of functions like VG_(open), and also to cover any future changes between now
and the HEAD becoming an official release.
Previously, if the command given to Valgrind didn't exist, the 'stat -c'
suid/sgid test failed, and the startup script aborted with an ugly message.
I've changed it so that it first checks that the program exists in the user's
path (as determined by 'which'), and aborts if not.
This was quite fiddly to get right; yell if I've broken anything.
Add a --assume-2.4=yes|no CLO. This overrides the normal check to see
if the kernel has enough capabilities to run in 2.6 mode (ie, futex,
the right kind of clone, correct signal handling properties), and always
uses 2.4 mode. This will often not work on a 2.6 or RH9 2.4 kernel, but
it does help avoid a bug in the SuSE 8.2 (and possibly 9) kernels, which
look like they support enough to run in 2.6 mode, but get it wrong.
TODO: make the startup script/configure actually use this option.
Also some cleanup in printing debugging messages from vg_proxylwp.c, and
a small fix in the handling of ERESTARTSYS (assume that every syscall will
get interrupted from the outset, until it actually completes).
Update some stuff related to the syscalls change:
- restart syscalls which return ERESETARTSYS
- make code to restart a syscall common
- keep a process-wide pending signal set to store as-yet
undelivered signals (only used in 2.4 mode; TODO: siginfo, queues)
- make execve work a bit better - it is impossible to recover from
execve failing, so we try to check that it will before running the
syscall itself (also fixes bug with SuSE 8.2 kernel)
Julian Seward [Sun, 19 Oct 2003 08:18:52 +0000 (08:18 +0000)]
SSE/SSE2 fixes needed to run the entire test suite of the GNU
Scientific Library (gsl-1.4) compiled with Intel Icc 7.1 20030307Z '-g
-O -xW'. I think this gives pretty good coverage of SSE/SSE2 floating
point instructions, or at least the subset emitted by Icc. So far
tested on memcheck and nulgrind; addrcheck and cachesim still testing.
Change things so that helgrind regtests pass on my machine -- changed stderr
filters to strip out varying things, and changed outputs correspondingly. Yell
if this breaks them for you.
Dirk Mueller [Fri, 17 Oct 2003 13:43:46 +0000 (13:43 +0000)]
- add test to detect if GNU as supports .cfi directives
- correct stack-boundary test. this test is apparently redundant
as it always passed, and nobody complained ;)
Dirk Mueller [Thu, 16 Oct 2003 14:19:27 +0000 (14:19 +0000)]
provide CFI for newer gdb versions which are confused by our stack
manipulations otherwise. These macros are probably not implemented in
older gas versions. We'll see when people complain, but otherwise
this is a very good candidate for
MERGE TO STABLE
as it fixes --gdb-attach=yes for any recent distro.
When creating a logfile name, add a sequence number to the name in case
a logfile for that pid already exists. This may happen for programs
started during system boot which will tend to get the same pid each boot.
Adds VG_(describe_addr)() for generating symbolic descriptions of a
memory address, based on which variables are in scope at the time and
their types.
As part of this change, I restructured the symbol table parsing code,
by splitting the stabs and dwarf-specific parts into their own files.
I also added a new set of vg_symtypes.[ch] files which contains the
type system code and the core of the VG_(describe_addr)().
I've only implemented the stabs type parser. I have not yet implemented
the DWARF2 parser. It looks well-defined but complex.
The only skin which uses this is Helgrind at the moment.
This creates a new UInstr for multiply. This is mainly so that memcheck
can treat it like add and generate partially-defined results of multiply
with partially defined arguments. It may also speed things up a bit,
if they use lots of multiplies.
This change only deals with signed "new style" multiplies. That the x86
has two quite different kinds of multiply instructions: the "old-style"
signed and unsigned multiply which uses fixed registers (eax:edx) and
generates a result twice the size of the arguments, and the newer signed
multiple which takes general addressing modes. It seems that gcc always
(almost always?) generates the new signed multiply instructions, except
for byte-sized multiplies.
A complete reworking of Valgrind's handling of system calls and signals,
with the aim of making it more robust, more correct and perhaps faster.
This patch removes the need to poll blocking syscalls, by adding a proxy
LWP for each application thread. This LWP is a kernel thread whose job
is to run all (potentially) blocking syscalls, and also to handle signals.
This allows the kernel to do more of the work of dealing with signals,
so on kernels which do this properly (2.6), Valgrind's behavious is a
lot more posix compliant. On base 2.4 kernels, we emulate some of the
missing 2.6 functionality.
Julian Seward [Sun, 12 Oct 2003 10:27:06 +0000 (10:27 +0000)]
Delete some "inline" directives on functions that gcc-3.3.1 declined
to inline. This is needed to get a warning-free compilation on 3.3.1.
It seems we had "inline" on some pretty huge functions in places.
Also it appears gcc-3.3.1 won't inline a function call in a tail call
position, reasonably enough. I assume in that case it prefers to
create a tailcall to the callee, rather than inlining it.
because they weren't being intercepted, and called malloc(), which caused bogus
mismatch errors.
Added a regression test for it, too.
MERGE TO STABLE (although the change to vg_replace_malloc.c won't quite be a
cut and paste job, because of prior changes made to it in the head
but not the stable branch; merge will still be easy, though)
Julian Seward [Tue, 7 Oct 2003 00:18:16 +0000 (00:18 +0000)]
Rudimentary, kludgy, incomplete and probably just plain wrong support
for vendor_id "CentaurHauls", which is the VIA string (reflecting its
design heritage). Currently pretend to be something like a VIA Nehemiah.
Moved the MALLOCLIKE and FREELIKE client requests out of memcheck.h, and into
valgrind.h. Although these requests are not implemented by the core, they can
be implemented by skins that track heap blocks, eg. Memcheck, Annelid, Massif.
This is in preparation for committing Massif to the repository.
I think I managed to make the change in a binary-compatible way. The only
inconvenience for users is that if they have a client program compiled with the
old requests in, Valgrind will abort with an explanatory message that tells
them to recompile. Once they've done that (no changes to their program are
required), it works again.
Fixed up the client request info in the docs, which required splitting the core
requests from the Memcheck requests and putting the descriptions in the
appropriate parts of the docs.
Removed the __VALGRIND_SOME_SKIN_H test -- it was designed to prevent people
#including valgrind.h when they probably want memcheck.h, but it's actually a
reasonable thing to do to #include valgrind.h alone, because there are some
requests in valgrind.h.
Removed references to VALGRIND_MAKE_NOACCESS_STACK from the docs, as it doesn't
exist in the implementation.
Improved the ESP-update pass -- it's method for finding the ESP-deltas was very
fragile, and it was lucky that it worked at all. Replaced it with a much more
robust method. Thanks to Dirk Mueller for pointing it out.
Dirk Mueller [Wed, 1 Oct 2003 10:19:08 +0000 (10:19 +0000)]
speed optimisation: assuming that a tempreg not related to %esp before
is PUTed into %ESP, we do *know* that this tempreg points to %ESP afterwards,
so track it.
reduces the amount of expensive "DO_GENERIC" calls by 75% in Khtml. I've
not observed a problem with it, but consider it experimental.
The name-mangled versions of __builtin_new() and __builtin_vec_new() now
don't just call the unmangled versions, but do the appropriate stuff
themselves directly (this was necessary for Massif). This means that stack
traces for them have one fewer function. And I was able to gather up several
very similar functions into a macro, reducing the amount of code, which was
nice. Had to update one regtest's expected output accordingly.
Added a new flag ',' to printf() format specifications. When specified in a
number, will print it with commas delimiting it. Very useful when printing
large numbers.
Using it, was able to remove the wretched commify() function from Cachegrind.
Made VG_(read_millisecond_timer)() available to skins. Also made it cope
with being called from SK_(pre_clo_init)(), before its startup code has been
run (just returns 0).
Change things so that default.supp is only deleted with "make distclean",
rather than "make clean", which is the behaviour recommended by the automake
docs for files built at configure-time.