string in valgrind.pc.in, so that they describe Valgrind as a "dynamic
binary instrumentation framework", and don't mention platforms at all.
I had to tweak the regtest filters a bit for this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3178
Int VG_(do_syscall) ( UInt, UWord, UWord, UWord, UWord, UWord, UWord );
to replace the previous:
Int VG_(do_syscall) ( UInt, ... )
Reason being that sometimes you could get incorrect args passed, when
passing 32-bit ints on 64-bit platforms. I also added macros
VG_(do_syscall[123456]) to make life easier, and converted all the
relevant calls.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3143
significantly reduces the number of client requests made by programs
which make intensive use of the pthread_ functions, such as
OpenOffice.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3131
- Added include/x86-linux/ and include/linux/ subdirectories, with Makefile.am
files.
- Overhauled the definitions of kernel types. include/vg_kerneliface.h is now
three files, include/linux/vki.h, include/x86-linux/vki_arch.h, and
include/x86-linux/vki_arch_posixtypes.h. These files separate the
common/Linux and x86/Linux parts cleanly. All code is copied verbatim from
the relevant kernel headers, except that VKI_/vki_ prefixes are added as
necessary to distinguish them from glibc types. (This is done consistently,
unlike previously when some types did not have the prefixes.)
All code is clearly marked to show which particular header file it came from,
and the Linux version used. (I used 2.6.8.1, the most recent stable release,
for all of them.)
A few of the types changed; this is because they changed between the older
versions of Linux and the current 2.6.8.1. I checked that all these changes
were ok with respect to backwards compatibility for our purposes.
- vg_unsafe.h has been removed; we are no longer including any kernel headers,
as we have our own copies for everything. This is because installed kernel
headers are not reliable, and often cause compilation problems. (bug
#92420 is a recent example)
- Removed some no-longer-needed header-presence tests from configure.in.
- Some code in the rest of Valgrind was changed to account for some slight
changes in the names of our VKI_/vki_ kernel constants and types.
- Updated README_MISSING_SYSCALL_OR_IOCTL accordingly.
- Fixed off-by-one error with VKI_GDT_ENTRY_TLS_MAX (merged from stable branch)
The end result is that the kernel types situation should be much clearer, and
similar files can be created relatively easily for other architectures as
necessary.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2884
- Factored out the remaining arch-specific code from vg_libpthread.c.
- Also fixed up the build process for x86/libpthread.c, which was done
wrongly in the previous commit.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2798
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.
This fixes bug 76845.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2781
in a similar way to the previous patch that removed the limit on the
number of semaphores and fixes bug 86264.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2776
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.
BUG: 88614
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2772
__attribute((regparm(n))) with REGPARM(n) everywhere. REGPARM() is defined in
vg_skin.h, but will eventually be defined separately for each arch.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2601
for the original function with RTLD_NEXT doesn't work then try looking
for the __libc_ version of the function the RTLD_DEFAULT instead.
The reason for this is that, contrary to the dlsym documentation, it
seems that RTLD_NEXT doesn't always seem to find the definition that
would have been used if it weren't for the override. This is particularly
common wihen libpthread is pulled in implicitly by a dependency from
another library.
This should hopefully fix bug #85658.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2595
that it is called as soon as libpthread.so is loaded even if pthread_create
is never called.
This ensures that pthread_exit will work correctly, and I think will also
cure the famous memory leak in the pthread specifics for the main thread.
CCMAIL: 86730-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2584
flag before the call to __uselocale() in order to avoid deadlock.
CCMAIL: 77952-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2493
stack attribute related functions work properly as it seems to be a
sensible thing to improve even if it isn't enough to get the JVM running
under valgrind now.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2444
handlers when a thread is cancelled which has the side effect that
programs linked with librt fail on Fedora Core 2 due to librt having
been built against the NPTL header instead of the old pthread headers.
This change extends valgrind's libpthread.so to handle both the old
and new style cleanup handlers in a similar way to NPTL and seems to
be sufficient to get programs linked with librt working again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2405
it isn't clear why we were intercepting that and only aliasing accept
to it. Switched to intercepting accept directly instead.
CCMAIL: 76869-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2404
libc version of the wrapped function when forwarding the call rather
than trying to call the internal __libc_xxx version of the routine
as many of those are marked as GLIBC_PRIVATE in recent releases.
CCMAIL: 82026-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2402
is missing was reported in bug #70344 but the reporter then closed the
bug saying that they were using the wrong version of valgrind.
Patch from Henrik Algestam <algestam@home.se>.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2346
client code (in vg_libpthread.c) to set the appropriate signal mask when
its ready. This prevents a bug where a thread gets sent a signal before
even running any of its initialization code, which can cause problems
(particularly if the signal handler directly or indirectly uses TLS).
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2332
being able to use malloc as the libc malloc tries to use thread specific
data and we wind up in a recursive nightmare.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2293
2.3.3, which is binary-compatible, but not source compatible with the old one,
which came from LinuxThreads. We were using the types defined in the old one,
which caused compilation errors on systems using the new one.
This commit introduces our own versions of these types. Our versions are laid
out identically to the LinuxThreads ones, but the field names are different.
We convert all pthread types to our versions before using them, so we don't
rely on the pthreadtypes.h types any more. Hopefully this will fix the
problem; I have three reports that it does. Let's see...
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2272
threads to have thread-private data which is quickly accessible via a
segment in the GDT, stored in %gs. The patch implements the relevent
syscalls (setthreadarea), and also manages switching the VCPU's segment
information at thread context-switch time. Mostly Tom Hughes' work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2215
This patch fixes a semaphore leak within valgrind. If your application
dynamically allocates/releases semaphores, you will very quickly run out.
Also, as a nice side effect, it implements sem_destroy properly.
(me)
Protect sem_getvalue with a lock/unlock of the semaphore's mutex,
like the other routines do.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2153
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
"kludged" confusing. Even printing out brief explanations of why functions are
ignored/kludged, in some cases.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2054
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
