__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
properly with POSIX, and not get assertion failures when the same
thread makes nested calls to pthread_once with different once_control
pointers.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1746
- Change various incorrect direct references to errno into
*(__errno_location()).
- In __errno_location and __h_errno_location, treat the tid==1 case
(root thread) specially, as with __res_state().
This seems to fix a bug in threaded handling of errno on R H 9 and SuSE8.2,
and almost makes OpenOffice work again on R H 9.
MERGE TO STABLE, if it doesn't break anything.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1625
because there was no point exposing them to clients, as they don't know the
ThreadState type.
Also, removed the LOGMESSAGE request type, replaced it with calls to
VG_(message) via the generic VALGRIND_NON_SIMD_CALL2.
In fact, almost every single pthread client request could be removed in this
same way. That would result in less code, which would be nice... yeah, real
nice.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1584
NPTL support.
The behaviour of weak vs strong symbols seems to have changed in
glibc-2.3.2. This caused problems in coregrind/vg_intercept.c,
wherein strong symbols in vg_libpthread.c were intended to
override weak symbols in vg_intercept.c, in order to give alternative
thread-safe implementations of some functions, poll(), select(), etc.
The change involves moving the nonblocking implementations of poll, etc
into vg_intercept.c, renaming them to (eg) VGR_(poll), and routing
all calls to poll to VGR_(poll) [dually for other such fns]. This
means even single-threaded programs now use these functions, but
that doesn't strike me as harmful.
MERGE TO STABLE, if it doesn't break anything
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1559
The veneers for msgrcv in vg_intercept.c and vg_libpthread.c are not
returning the number of bytes read correctly - they always return zero
for any non-error case, which causes programs using msgrcv to behave
somewhat non-optimally when running under valgrind ;-)
Attached is a patch against 1.9.3 which fixes this.
Tom
--
Tom Hughes (thh@cyberscience.com)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1424
