Julian Seward [Wed, 12 Oct 2005 10:09:23 +0000 (10:09 +0000)]
Redo the way cachegrind generates instrumentation code, so that it can
deal with any IR that happens to show up. This makes it work on ppc32
and should fix occasionally-reported bugs on x86/amd64 where it bombs
due to having to deal with multiple date references in a single
instruction.
The new scheme is based around the idea of a queue of memory events
which are outstanding, in the sense that no IR has yet been generated
to do the relevant helper calls. The presence of the queue --
currently 16 entries deep -- gives cachegrind more scope for combining
multiple memory references into a single helper function call. As a
result it runs 3%-5% faster than the previous version, on x86.
This commit also changes the type of the tool interface function
'tool_discard_basic_block_info' and clarifies its meaning. See
comments in include/pub_tool_tooliface.h.
Julian Seward [Tue, 11 Oct 2005 22:06:29 +0000 (22:06 +0000)]
Make sync checking work on recent x86 kernels (eg SuSE 10) which mark
many 'r' sections also as 'x' because x86 can't really distinguish
them. The change just regards 'x' and 'r' as equivalent on x86.
Checking on ppc32/amd64 is unchanged.
Update cache simulator for 64 bit addresses. This probably won't have
caused many inaccuracies so far because it only matters if addresses
above the 4GB line are used. Thanks to Josef W for the patch.
Julian Seward [Fri, 7 Oct 2005 12:13:21 +0000 (12:13 +0000)]
ppc32 only: improve handling of CmpORD32S, so as to avoid false
positives from ppc code of the form "cmpi %reg,0 ; branch-if-negative
.." where the top bit of %reg is defined but not all of the other bits
are (common-ish enough to cause a considerable number of false
positives if not done right).
Julian Seward [Fri, 7 Oct 2005 11:08:55 +0000 (11:08 +0000)]
Fix the handling of CmpORD32{S,U} which was completely bogus and
would have caused ppc32 to miss many uninitialised value errors.
(Change affects ppc32 only).
Julian Seward [Fri, 7 Oct 2005 09:49:53 +0000 (09:49 +0000)]
Fix a memcheck anomaly observed by Nick: lazy propagation of
undefinedness was not being done properly for scalar shifts and that
could have led to undefined-value errors being falsely reported in the
obscure case where the shift amount was undefined but the end result
of the shift was unused. This commit handles shifts more in
accordance with the maximally-lazy V-bit-testing scheme used by the
rest of memcheck.
Tom Hughes [Thu, 6 Oct 2005 14:49:21 +0000 (14:49 +0000)]
When looking for a heap segment to extend look for the heap limit
address rather than the base address as the heap may have been split
into more than one segment by using mprotect on it...
Tom Hughes [Thu, 6 Oct 2005 09:00:17 +0000 (09:00 +0000)]
Fix realloc wrappers to handle the out of memory case properly - if
the call to VG_(cli_malloc) returns NULL then don't try and copy the
data or register a new block and just leave the old block in place
instead, but still return NULL to the caller.
Changed some overflow-prone counters from UInt to ULong.
Changed some printf specifiers accordingly, plus some more that were
incorrect.
Also put commas in various output numbers, eg. the leak check stats.
This makes them much easier to read when they get big. One
exception is in XML number-only fields such as <leakedbytes>.
Julian Seward [Thu, 6 Oct 2005 03:19:49 +0000 (03:19 +0000)]
The m_syswrap subsystem is Valgrind's model of how the kernel behaves
with respect to syscalls. It is detailed and comprehensive but does
not offer a way to deal with minor deviations in behaviour from the
vanilla kernel sources, either due to running a hacked kernel or
running a vanilla kernel with a custom kernel module loaded.
This commit adds a flexible way to handle such cases without polluting
the vanilla handler syswrap-*.c files or their supporting vki_*.h
header files. For each OS, a syswrap-OS-variants.c file is added,
containing wrappers for variants of OS. A new command line flag
--kernel-variants= carries a comma separated list of variant names
that apply to the current run. There are no other changes.
Julian Seward [Tue, 4 Oct 2005 23:07:33 +0000 (23:07 +0000)]
If the launcher can't figure out what it's own name is, don't bail
out. Instead, print a warning message, continue, and cause any
attempt to trace into a child process to fail with ECHILD.
Tom Hughes [Tue, 4 Oct 2005 16:54:54 +0000 (16:54 +0000)]
Make sure we have all the DWARF2 sections before trying to decode
any DWARF2 debug information. All make sure we don't fall over if
the .debug_info is less than four bytes long. Fixed bug 113642.
Tom Hughes [Tue, 4 Oct 2005 15:59:54 +0000 (15:59 +0000)]
Create a new SkShmC segment type for shared memory segments so that we
can ensure they are never merged with adjacent segments. This makes
sure that we can find the right piece of memory to release when the
shmdt system call occurs.
Make the dispatch files platform-specific, not just arch-specific,
as requested by Greg Parker. (The ppc32/Darwin dispatch loop is
different to the ppc32/Linux one, for example.)
Tom Hughes [Fri, 30 Sep 2005 08:07:53 +0000 (08:07 +0000)]
Rationalise the mmap system call handling - after examining the kernel
source it turns out that there are five different versions of mmap for
the three platforms we currently support:
- On x86-linux there is mmap (aka old_mmap) which takes the
arguments in a memory block and the offset in bytes; and
mmap2 (aka sys_mmap2) which takes the arguments in the normal
way and the offset in pages.
- On ppc32-linux there is mmap (aka sys_mmap) which takes the
arguments in the normal way and the offset in bytes; and
mmap2 (aka sys_mmap2) which takes the arguments in the normal
way and the offset in pages.
- On amd64-linux everything is simple and there is just the one
call, mmap (aka sys_mmap) which takes the arguments in the normal
way and the offset in bytes.
To reconcile all this I have created a generic handler and then
written five platform specific wrappers which normalise all the
arguments and then call the generic handler.
I have also modified the address space manager to use mmap2 rather
than mmap on x86 and ppc32 so that large offsets can be correctly
handled.
There is still an issue of OffT truncating offsets as we go through
the address space manager that will need to be addressed.
A corresponding fix to 4823: don't deal with MAP_FIXED case directly
here; instead uniformly pass all requests to VG_(am_get_advisory), so
that layout policy is controlled from one place only.
- don't deal with MAP_FIXED case directly here; instead uniformly pass
all requests to VG_(am_get_advisory), so that layout policy is controlled
from one place only.
Tom Hughes [Thu, 29 Sep 2005 23:26:06 +0000 (23:26 +0000)]
On x86 and ppc32 the offset argument to mmap2 is specified in pages
not bytes. This is a horrible kludge of a fix and it should probably
be fixed properly with a separate sys_mmap for amd64.
Fix a very stupid bug in the new aspacemgr, in which mmap "hint-style"
requests were being granted at the requested address when they should
not have been. This was causing ppc32-linux to crash at startup
(since the wrongly-granted mapping annihilated 5 others). This shows
the value of a multiplatform approach -- the bug applies to all
targets, yet x86 and amd64 appeared to work perfectly.
projects / thirdparty / valgrind.git / log
