Julian Seward [Tue, 19 Oct 2004 01:03:46 +0000 (01:03 +0000)]
Remove all references to hardwired guest state offsets. Instead,
allow definition of a struct containing the guest state (eg,
VexGuestX86State in pub/libvex_guest_x86.h) and derive all offsets
from that struct.
Tom Hughes [Mon, 18 Oct 2004 18:56:25 +0000 (18:56 +0000)]
Use tgkill instead of tkill if it is available. This is the newer and
safer kernel interface to signalling a particular thread and it ensures
you can only send a signal to one of your own threads.
Arch-abstraction: fix up valgrind.h for future inclusion of other
architectures. Had to recast it as valgrind.h.in; now at configure time the
appropriate #define is set so that the appropriate snippet of assembly code is
chosen. It's done this way rather than with x86/ etc. directories like the
rest of Valgrind, because this header file must stand alone for inclusion by
other programs.
Arch-abstraction:
- factor out the setting of syscall results, which can be more complicated
than just putting a value in the result register (eg. PPC has to fiddle with
multiple registers).
Julian Seward [Mon, 18 Oct 2004 14:09:54 +0000 (14:09 +0000)]
Restructure the x86->IR phase somewhat, so that it can optionally
disassemble across basic block boundaries, when branch destinations
are known (calls to known locs, unconditional branches to known locs).
This can significantly improve performance for some programs.
Arch-abstraction: a nice change that removes the need for ume_entry.S. Instead
of using an assembly hack to find the stack pointer at startup, we find it from
argv. It's much simpler, avoids linking games, is platform independent, and
works on PPC.
Tom Hughes [Sun, 17 Oct 2004 15:18:22 +0000 (15:18 +0000)]
Fix problems with very long timeouts given when waiting on a mutex or
condition variable. The pthread routines now use a timeout of 0xfffffffe
if the user asks for something longer than that otherwise we will wrap
around and actually get a much shorter timeout.
The scheduler has also been changed so that it it now limits itself to
a timeout of 0x7fffffff when working how how long to poll for. This won't
affect how long a thread actually sleeps for as we'll just wind up waiting
a bit more on the next pass round the loop.
Tom Hughes [Sat, 16 Oct 2004 16:50:14 +0000 (16:50 +0000)]
When returning from handling a signal check whether any mutex that the
thread was waiting on has been unlocked while the signal handler was
running and resume the thread if it was.
Tom Hughes [Sat, 16 Oct 2004 16:17:06 +0000 (16:17 +0000)]
If a thread is waiting on a mutex or condition variable when a signal is
delivered that the thread state is temporarily changed from WaitMX or WaitCV
to Running while the signal handler is running. The original state is then
restored when the handler returns.
This patch forces the associated_mx and associated_cv values to be cleared
at the same time and the original values restored afterwards. Without this
the scheduler state will not be considered sane while the handler is running.
This is based on a patch from Kenneth Schalk and fixes a problem he had
with posting to a semaphore in a signal handler. It also allows a couple
of assertions in the scheduler sanity check to be uncommented.
Tom Hughes [Sat, 16 Oct 2004 14:49:53 +0000 (14:49 +0000)]
Remove the limit on the number of pthread read/write locks. This works
in a similar way to the previous patch that removed the limit on the
number of semaphores and fixes bug 86264.
Tom Hughes [Sat, 16 Oct 2004 10:59:49 +0000 (10:59 +0000)]
When signal routing is in use (because we are running on an older kernel
that doesn't route signals to the correct threads properly) the siginfo
data was not being propagated to any signal handlers installed by the
client program.
This is because the main thread routes the signal to the proxy LWP by
using the tkill system call but that then appears in the proxy as a user
initiated signal and the original siginfo data is lost.
This patch adds a small queue of siginfo data for pending sigals to
each thread's state so that when the proxy LWP passes the signal back
to the main thread the relevant siginfo data can be recovered and passed
on to any signal handlers. Thix fixes bug 91325.
Tom Hughes [Sat, 16 Oct 2004 10:50:11 +0000 (10:50 +0000)]
Yet another attempt to quash the assertions in the pthread forwarding code.
It appears that the resolution of the address is to forward to is now
working properly but that on some systems the second part of the assertion
fails because the dynamic linker resolves the name of the function being
forwarded to the glibc version rather than the version in valgrind's pthread
library.
The solution is to use dlopen to explicitly obtain a handle to valgrind's
pthread library and then lookup the symbol with dlsym when doing the
comparison in the assertion.
Tom Hughes [Sat, 16 Oct 2004 10:46:01 +0000 (10:46 +0000)]
It seems there are some kernels around where the getpid system call has
been changed to return the ID of the thread group leader but which do not
have a gettid system call.
This breaks VG_(gettid) which assumes that the getpid system call will
give the thread ID if the gettid system call does not exist.
The (horrible) solution is to use readlink to see where /proc/self points
when the gettid system call fails.
Julian Seward [Thu, 14 Oct 2004 21:40:12 +0000 (21:40 +0000)]
Finally resolve compilation warnings in iropt.c pertaining to the
casts of pointers to/from the 64-bit hash values. Instead, invent a
type 'HWord' which is the same size as a pointer on the host. Check
all data sizes at library initialisation, for sanity purposes. Use
HWord instead of ULong for the association tables in iropt.c. This
has the added advantage that it makes iropt a bit faster and less
space-hungry on 32-bit hosts, since HWord is 32-bits on a 32-bit host.
Added a unit self-test -- a test program that incorporates a small part of
Valgrind itself (the files ume.c, ume_entry.c and jmp_with_stack.c). Thus,
we are using Memcheck to check these files in a unit test setting.
I hope to do unit self-testing for many more parts of Valgrind, eventually all
the bits that can be pulled out into any kind of sensible stand-alone form.
Doing so achieves two things:
a) it introduces unit testing into our framework (a serious shortcoming at the
moment)
b) it lets us use Valgrind (esp. Memcheck) on itself, to some extent
This should help reliability. This first unit self-test isn't very exhaustive,
but it's a start.
Note that this involves something like bootstrapping, in that we are checking
parts of a Valgrind build with itself. I don't think this will be a problem,
since we (at least, I do) tend to only run the regtests when we think the
Valgrind build is ok.
Some combined cleaning up and arch-abstraction, involving UME and start-up:
- removed some assumptions that arch==x86 in Makefile.am files
- removed ume_arch.h; moved its contents into ume.h. There was no need for
these to be separate.
- moved ume_go.c into an x86/ subdir; gave it the more meaningful name
jmp_with_stack.c in the process (the corresponding function also got the name
change)
Julian Seward [Wed, 13 Oct 2004 17:08:42 +0000 (17:08 +0000)]
Disable CSEing of loads as it's incorrect until such time as the CSEr
invalidates ld-based available expressions when going past stores or
dirty helper calls.
Julian Seward [Wed, 13 Oct 2004 14:50:14 +0000 (14:50 +0000)]
Add loop unrolling to iropt (simple, crude first attempt). This also
required finally biting the bullet and making a proper set of deep-copy
constructors for IR (the dopy* functions).
Arch-abstraction:
- move LDT stuff out of core, into x86-linux specific stuff. Some of it
(VG_(do_useseg)()?) may be really x86-specific, rather than
x86/linux-specific, but that can be fixed later if it's really shared with
another OS.
Fix for bug 91162: cope with jumps to bogus addresses when there is a SEGV
signal handler present -- previously, Valgrind would abort unnecessarily on
this case.
Julian Seward [Tue, 12 Oct 2004 13:44:12 +0000 (13:44 +0000)]
Extend CSE so it commons up F64i literals. This also requires changes
in the flattener -- to lift out F64is in the first place -- and in the
constant propagator, to not propagate them back into expressions.
Julian Seward [Tue, 12 Oct 2004 09:47:15 +0000 (09:47 +0000)]
More cleanups of PutI/GetI transformations:
* PutI-GetI forwarding: check that the forwarded value is of the
same type as the original GetI'd value
* findPutI: use getAliasingRelation_IC/getAliasingRelation_II.
projects / thirdparty / valgrind.git / log
