I added a test case and cleaned up vg_dispatch.S while I was about it.
CCMAIL: 69529-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2129
--branchpred=yes. I'm interested to know if these make a significant
difference for anyone - I see a small speed increase on the Pentium M.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2126
Valgrind's dependency on the dynamic linker for getting started, and
instead takes things into its own hands.
This checkin doesn't add much in the way of new functionality, but it
is the basis for all future work on Valgrind. It allows us much more
flexibility in implementation, and well as increasing the reliability
of Valgrind by protecting it more from its clients.
This patch requires some changes to tools to update them to the changes
in the tool API, but they are straightforward. See the posting "Heads
up: Full Virtualization" on valgrind-developers for a more complete
description of this change and its effects on you.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2118
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2013
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
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1974
of functions like VG_(open), and also to cover any future changes between now
and the HEAD becoming an official release.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1969
- 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
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
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
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.
Fixed a few other minor things.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1880
with being called from SK_(pre_clo_init)(), before its startup code has been
run (just returns 0).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1868
and Nick but got no reply. I guess they're okay with it. I tested them
quite a lot so it should be fine.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1834
how stack snapshots are taken and printed; they can be used in preference
to VG_(get_ExeContext)() and VG_(pp_ExeContext)(). These are used by
Massif, my heap profiling skin.
Changed --num-callers to allow a backtrace size of 1.
Added code so that when Valgrind fails to disassemble an instruction, the
instructions line/file and address are printed out, which makes it easier to
work out where and what it is. Required the stack snapshot changes above.
MERGE TO STABLE?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1819
from skin's view, replacing all instances with ThreadId. Much cleaner. Had to
change the way VG_(get_ExeContext)() worked a little. Changed the core/skin
major interface because this breaks the old version. Also fixed a few minor
related things here and there.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1782
had forgotten that some errors (PThread errors) are found by the core, rather
than skins and so the skin shouldn't be involved in handling them. This commit
fixes the problem.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1770
problem which caused the leak checker to misbehave following recent
PLT-bypass workaround.
In short, it is an error to announce to the skin, segments found which
belong to the low-level memory manager, because the skin may then mark
them as accessible to the client. This is wrong, and the client
should only acquire accessible memory via malloc etc and stack
movement. Now we carefully avoid mentioning any segment belonging to
the low level memory manager.
Take the opportunity to improve VG_(within_m_state_static) so that it
also detects pointers within the thread table. This can reduce the
number of blocks the leak checker spuriously thinks are still
reachable.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1751
a way consistent with the position of the register field in the
instruction. In Intel encoding parlance, the G register is in bits
5,4,3 and the E register is bits 2,1,0, and so we adopt this scheme
consistently. Considering how much confusion this has caused me in
this recent bout of SSE hacking, consistent renaming can only be a
good thing. It makes it a lot easier to figure out if parts of the
SSE handling machinery are correct, or not.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1698
