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
they rely on this area being unmapped for their quick sanity check. This
commit make Valgrind refuse to mmap() this area. Added a regtest for it.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2085
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
- 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
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
Renamed:
VG_(read_procselfmaps_contents)() --> VG_(read_procselfmaps)()
VG_(read_procselfmaps)() --> VG_(parse_procselfmaps)()
VG_(read_symbols)() --> VG_(read_all_symbols)()
VG_(read_symtab_callback)() --> VG_(read_seg_symbols)()
Removed the Bool 'read_from_file' arg from (what is now)
VG_(parse_procselfmaps)(). If /proc/self/maps needs to be read beforehand, the
code calls (what is now) VG_(read_procselfmaps)() before. Still using the
static buffer which is not nice but good enough.
More importantly, I split up VG_(new_exe_segment)() into
VG_(new_exeseg_startup)() and VG_(new_exeseg_mmap)(). This is because at
startup, we were stupidly calling VG_(read_symbols)() for every exe seg, which
parses /proc/self/maps completely in order to load the debug info/symbols for
the exe seg (and any others we haven't already got the symbols for). Despite
the fact that the startup code reads /proc/self/maps to know which segments are
there at startup. In other words, we were reading /proc/self/maps several
times more often than necessary, and there were nested reads, which Stephan
Kulow's recent depth patch fixed (but in a pretty hacky way; this commit fixes
it properly). So VG_(new_exeseg_startup)() now doesn't cause /proc/self/maps
to be re-read. Unfortunately we do have to re-read /proc/self/maps for mmap(),
because we don't know the filename from the mmap() call (only the file
descriptor, which isn't enough).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1830
count. Added a regression test for it.
Updated the basic test stderr filter to strip out line numbers from
vg_intercept.c
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1812
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
Removed the SK_(written_shadow_regs_values)() function. Instead, skins that
use shadow regs can track the `post_regs_write_init' event, and set the shadow
regs from within it. This is much more flexible, since it allows each shadow
register to be set to a separate value if necessary. It also matches the new
shadow-reg-change events described below.
In the core, there were some places where the shadow regs were changed, and
skins had no way of knowing about it, which was a problem for some skins.
So I added a bunch of new events to notify skins about these:
post_reg_write_syscall_return
post_reg_write_deliver_signal
post_reg_write_pthread_return
post_reg_write_clientreq_return
post_reg_write_clientcall_return
Any skin that uses shadow regs should almost certainly track these events. The
post_reg_write_clientcall_return allows a skin to tailor the shadow reg of the
return value of a CLIENTCALL'd function appropriately; this is especially
useful when replacing malloc() et al.
Defined some macros that should be used *whenever the core changes the value of
a shadow register* :
SET_SYSCALL_RETVAL
SET_SIGNAL_EDX (maybe should be SET_SIGNAL_RETVAL? ... not sure)
SET_SIGNAL_ESP
SET_CLREQ_RETVAL
SET_CLCALL_RETVAL
SET_PTHREQ_ESP
SET_PTHREQ_RETVAL
These replace all the old SET_EAX and SET_EDX macros, and are added in a few
places where the shadow-reg update was missing.
Added shadow registers to the machine state saved/restored when signal handlers
are pushed/popped (they were missing).
Added skin-callable functions VG_(set_return_from_syscall_shadow)() and
VG_(get_exit_status_shadow)() which are useful and abstract away from which
registers the results are in.
Also, poll() changes %ebx (it's first argument) sometimes, I don't know why.
So we notify skins about that too (with the `post_reg_write_syscall_return'
event, which isn't ideal I guess...)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1642
(prerelease) (SuSE Linux)") seems to complain about signed-vs-unsigned
comparisons, when -Wall is on. This commit fixes (most of) those
complaints.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1638
- getcwd() now uses the result for the post_mem_write length rather than
the argument, which would have over-estimated
- accept(), recvfrom() and getsockopt() can now all take NULL buffers (which
are quite legitimate) without Memcheck giving spurious errors
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1579
to assume that all sockaddrs are non-NULL and non-zero in
length. This isn't always true, and when I ran a program that
used a NULL sockaddr through Valgrind it segfaulted. I believe
that the change that I made fixes this bug in general, but I
might be overlooking something.
From kclark@CetaceanNetworks.com (Kevin D. Clark)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1440
