Julian Seward [Tue, 17 Oct 2006 01:30:47 +0000 (01:30 +0000)]
Merge r6120:
Get rid of VG_(sigtimedwait) and replace it a simpler version,
VG_(sigtimedwait_zero), which polls for signals and returns
immediately. AIX doesn't have a sigtimedwait syscall, so in that case
try and implement VG_(sigtimedwait_zero) using various other signal
syscalls.
Julian Seward [Tue, 17 Oct 2006 01:28:10 +0000 (01:28 +0000)]
Merge r6112:
Changes resulting from porting to AIX5:
- Auxiliary primary map handling has been redone, so that the
performance penalty for hitting memory above the magic 32G limit is
much reduced, and also the number of usable maps is limited only by
how much memory is available. The current code has been tested on
64-bit AIX for processes up to about 8GB in size.
The auxiliary primary maps are now stored in an OSet, "auxmap_L2".
However, looking up in an OSet for each memory reference is
expensive. So the OSet is 'fronted' by 24-entry array which holds
pointers to the 24 most recently used auxiliary primary maps.
Accesses to this array are made faster by incrementally rearranging
it on every lookup (if the requested map is found in the array, it
is moved one element closer to the start of the array).
Logically speaking, auxmap_L1 is a cache of auxmap_L2. The L2-L1
relationship is one of inclusion; iow L2 is not a victim cache.
There is extensive new sanity check code for these structures.
- Along with the auxmap changes are semi-fast cases in mc_LOADVn_slow
and mc_STOREVn_slow. These catch naturally aligned, word-size loads
which fall into addressible memory, and handle them directly rather
than in a byte-by-byte fashion.
- Fix longstanding error with alignment checks in
{new,die}_mem_stack_N. Previously, these checked the alignment of
the new SP value without taking the stack redzone size into account.
This is only safe if the redzone size is 8-aligned. The right thing
to do is check alignment after adding on the redzone size.
- Add a new mechanism which allows specification, on the command line,
of address ranges which memcheck is to 'ignore'. Meaning that it
regards all writes to those ranges as acceptable and all reads from
those ranges as acceptable and returning initialised data. This is
done without disturbing the existing finally-balanced bitmap
machinery. Instead, in mc_record_address_error, just ignore the
error if the address falls inside an ignored-range.
There is a new command-line flag --ignore-ranges= to specify
the address ranges. Currently up to 4 non-overlapping ranges may
be specified.
This kind of thing is useful if you want to do some strange thing
like map a high-performance network card into memory and can't be
bothered to tell memcheck about it through the official channels
(intercepting syscalls/ioctls and telling aspacem about them.)
Julian Seward [Tue, 17 Oct 2006 01:23:07 +0000 (01:23 +0000)]
Merge r6102/6103:
A new module ("Initial Image"), whose purpose is to set up the
client's initial memory and register state before running it. On
Linux this does all the stack/auxv/envp stuff which was previously
done in m_main. On AIX5 the kernel prepares the process' initial
image, so there's nothing to be done there. But LD_PRELOAD doesn't
work on AIX5, so m_initimg sets up the client so as to start by
running a short bit of code which gets the kernel to load in the core
and tool preloads and then start the client.
As a result of this, m_main gets a lot shorter and cleaner.
Julian Seward [Tue, 17 Oct 2006 00:56:43 +0000 (00:56 +0000)]
Merge r6086:
Makefile.am changes for AIX5. Almost all boilerplate stuff fitting in
with the existing factorisation scheme. The only change of interest
is that configure.in now generates automake symbols of name
VGP_platform and VGO_os, whereas previously it just made VG_platform
which was a bit inconsistent with the VGP/VGO/VGA scheme used in C
code.
Julian Seward [Sat, 14 Oct 2006 19:26:10 +0000 (19:26 +0000)]
Create a new module, m_vki, and move all knowledge about the kernel
interface, except for the syscall numbers, into that. Mostly this
means moving include/vki-*.h to include/vki/vki-*.h.
include/pub_tool_basics.h previously dragged in the entire kernel
interface. I've done away with that, so that modules which need to
see the kernel interface now have to include pub_{core,tool}_vki.h
explicitly. This is why there are many modified .c files -- they have
all acquired an extra #include line.
This certainly breaks all platforms except x86. Will fix shortly.
Julian Seward [Sat, 14 Oct 2006 15:51:32 +0000 (15:51 +0000)]
Create a new module, m_vkiscnums, and move all the system call numbers
into that. Mostly this means moving vki_unistd-<plat>.h to
include/vki/vki-scnums-<plat>.h.
This updates the automatic detection of cache parameters
for x86 and amd64 according to revision 21 of
Intels x86 Architecture Software Developer Manual, Volume 2a.
Julian Seward [Thu, 5 Oct 2006 17:59:23 +0000 (17:59 +0000)]
A memory pool update from Graydon Hoare.
Here's an update to the mempool move / change client requests and sanity
checking. The following changes are present:
- Added one more (hopefully last) client request, a predicate to
test whether a mempool anchor address is currently tracked.
It turns out mozilla's arena-using code is sufficiently inconsistent
in its assumptions that it's very difficult to phrase the valgrind
client-request annotations without this request. Namely: sometime
arena-init and arena-free operations are assumed to be idempotent.
- Fixed a very rapid tool-memory leak in the mempool sanity check
routine. The previous version of the patch I posted would use all
memory even on my Very Beefy Test Machine within ~15 minutes of
browsing with firefox.
- Added a little logging code to print the counts of pools and chunks
active every ~10000 sanity checks, when running with -v.
callgrind_annotate: fix warnings with "--collect-jumps=yes"
This callgrind option produces lines starting e.g. with
"jfi" in the profile data files, which specifies a
source file change between a jump source and jump target.
This itself is meaningless for callgrind_annotate, as
it can not show jump information in its annotation.
However, such "jfi" lines can contain important mapping
info for a (file ID, file name) tuple - which leads to
further warnings and problems if ignored.
Callgrind: fix segfault when dumping after toggling instrumentation mode
This bug shows up when callgrind dumps data of a BB with 0 instructions
(the segfault only appears on x86_64; for x86 we were "lucky").
"BB with 0 instructions" happens when you switch on instrumentation
(and callgrinds call graph tracing starts with an emtpy shadow call
stack) in the middle of a run: Whenever the shadow callstack
is empty, but callgrind sees a return instruction (ie. a shadow
callstack underrun), it creates an artifical BB which is faked to
have called the function we are returning from.
This way, the call arc is noted and will appear in the dump.
When unmapping segments from below aspacem_minAddr, convert them back
into SkResvns, not SkFrees. Fixes #133694. Thanks to Tom Hughes for
patch and test case.
Callgrind: Fix failed assertion at toggling instrumentation mode
When instrumentation mode is switched off, we want to fully
reset callgrinds internal execution state, which includes
the shadow call stack and function stack for context generation.
The latter was not completely reset before.
The bug showed up when switching the instrumentation mode on for
the second time, leading to
Callgrind: callstack.c:211 (vgCallgrind_push_call_stack):
Assertion 'current_entry->cxt != 0' failed.
This commit also improves debug output a little bit.
Callgrind: Fix annotate script for data produced with --dump-instr=yes
I just noticed that this is still a little wrong, as counts for e.g.
"strcmp" from libc and "strcmp" from ld.so will make up only one entry,
with the object name randomly choosen... but otherwise, it matches
with the data shown by KCachegrind.
Julian Seward [Wed, 16 Aug 2006 14:22:29 +0000 (14:22 +0000)]
When handling mremap, disallow an expanding in-place remap if it would
trash some other segment as a result of the expansion. This fixes
#129866. I don't know if it is a good solution though. Causes
none/tests/mremap{,2} to fail now, although I think it is still OK.
mremap really is a semantic disaster area.
Julian Seward [Wed, 16 Aug 2006 01:48:19 +0000 (01:48 +0000)]
When a segment becomes free, and it is above aspacem_maxAddr, mark it
as SkResvn rather than SkFree, since doing otherwise causes the area
above aspacem_maxAddr - which starts out as SkResvn - to be polluted
with SkFree bits. Fixes an assertion failure found by Alex Bennee
(users list, 9 Aug 06).
Also allow the preener to merge fixed-sized SkResvns so as to avoid
fragmentation that otherwise results.
Julian Seward [Tue, 1 Aug 2006 17:26:38 +0000 (17:26 +0000)]
Print the same text as micro_ops_warn on x86; doing otherwise defeats the
stderr filter for said text and so makes the test fail on Pentium-4's in
64-bit mode.
Followup to r5991: when leak checking, treat zero-sized blocks as if
they had size one. Otherwise they appear to cover no address space,
so no pointers to them are ever found, and so they are always
incorrectly marked as leaked.
projects / thirdparty / valgrind.git / log
