to query the CPU characteristics as the use of four implicit registers
causes havoc when GCC tries to inline and optimise the assembler.
Fix to bug #79696.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2421
- If no tool is specified, V now gives a short message and a list of
available tools. This was meant to happen previously, but a bug prevented
it from working properly; it gave the usage message instead.
- If a bad option is given, V now gives a short message rather than the full
--help. This make V consistent with all other programs I looked at.
- Now returning 0 when you do 'valgrind --help' and 'valgrind --version'
as other programs do.
- Removed VG_(startup_logging)() and VG_(shutdown_logging)() as they were
empty and have been for a long time (always?).
- Added various tests for these scenarios. Had to change the regtest
script slightly to allow for malformed command lines.
This addresses bug (wishlist) #82999.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2418
random address. This gets unmapped as part of the client setup, and
causes syscalls to fail as a result. This patch simply disregards the
sysinfo page. It seems like a blunt fix, but I don't think anything
depends on a sysinfo page.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2412
need to relock the associated mutex before running the cancellation
handlers.
This patch ensures that the mutex is reaquired in the above case and
also makes pthread_join and pthread_cond_wait act as cancellation points
as required by the POSIX threads standard.
Based on patch from Joseph Link <joelink@joelink.net>.
CCMAIL: 81297-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2409
containing the relevant debug sections and located using the information
in the .gnu_debuglink section of the main file along with some search
rules and checksum logic borrowed from binutils/gdb.
CCMAIL: 82872-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2408
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
a signal handler when VDSOs are turned off in FC2. Note that we don't
(yet) support VDSOs being on (use "echo 0 > /proc/sys/kernel/vdso").
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2400
ANSIfication of the hp2ps code. The most important changes are the correct
use of the stdarg mechanism (former hacks could bite on other systems, so
please tell upstream), inclusion of stdlib.h instead of declaring free
yourself, adding a few missed PROTO()s and using size_t for xmalloc and
xrealloc.:
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2399
Addrcheck wasn't doing overlap checking as it should. This is because
mac_replace_strmem.o was being linked with vgskin_addrcheck.so instead of
vgpreload_addrcheck.so. I fixed the Makefile, and also moved
_VG_USERREQ__MEMCHECK_GET_RECORD_OVERLAP so Addrcheck could see it. And I
added the 'overlap' test (from memcheck/tests/) to Addrcheck's regression
suite.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2394
with 2.2 kernels and, it seems, on some systems with 2.4 kernels.
CCMAIL: 79179-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2384
forked process before using ptrace() to continue it, instead of asking
ptrace to deliver it, as that doesn't seem to work on some versions
of linux.
CCMAIL: 77824-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2380
supplied by the operating system for the code, data and stack segments.
Explicit references using these segments still won't work but they
will at least produce an assertion to indicate that they aren't
supported instead of raising a segmentation fault in the target
program because of an apparent privilege violation.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2379
