- 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)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1964
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.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1955
filters to strip out varying things, and changed outputs correspondingly. Yell
if this breaks them for you.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1952
- correct stack-boundary test. this test is apparently redundant
as it always passed, and nobody complained ;)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1946
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1940
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1928
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1926
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1925
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1918
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.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1907
operator new(unsigned, std::nothrow_t const&)
operator new[](unsigned, std::nothrow_t const&)
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)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1899
for vendor_id "CentaurHauls", which is the VIA string (reflecting its
design heritage). Currently pretend to be something like a VIA Nehemiah.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1897
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.
I even updated the docs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1881