Make the allocator's access functions slightly stricter in their
checking of the lo/hi size fields. If we are corrupting the metadata,
this should make it more likely that we get an assertion failure rather
than an outright crash.
Julian Seward [Sun, 21 Aug 2005 00:48:37 +0000 (00:48 +0000)]
On a PPC32Instr_Call, don't merely record how many integer registers
carry parameters. Instead record the actual identities of such
registers in a bitmask. This is necessary because the PPC calling
conventions have "holes" in the register ranges. For example, a
routine taking an UInt(32-bit) first param and an ULong(64-bit) second
param passes the first arg in r3 but the second one in r5 and r6, and
r4 is not used.
Tom Hughes [Sat, 20 Aug 2005 16:26:04 +0000 (16:26 +0000)]
Make sure vex_svnversion.h is updated after an svn update and declare
the libvex.a target as phone to ensure that we always try and rebuild
it in case there have been changed in the VEX code.
Julian Seward [Fri, 19 Aug 2005 16:02:59 +0000 (16:02 +0000)]
Incorporate a patch from Craig Chaney which gives better stack
snapshots on ppc32-linux in the presence of functions subject to
leaf-function optimisations.
At the same time, simplify the stack unwinding logic by basically
implementing it separately for each target. Having a single piece of
logic for amd64 and x86 was tenable, but merging ppc32 into it is too
confusing. So now there is an x86/amd64 unwinder and a ppc32
unwinder.
This requires plumbing a link-register value into
VG_(get_StackTrace2), and that in turn requires passing it around
several other stack-trace-related functions. Hence 7 changed files.
Make it possible to match against "???" line in suppressions,
using "obj:*" or "fun:*". Also generate "obj:*" for such lines
with --gen-suppressions. Includes a regtest.
Julian Seward [Thu, 18 Aug 2005 11:54:30 +0000 (11:54 +0000)]
The strlen that ld.so uses on ppc32 causes a lot of false errors in
memcheck, and they are hard to get rid of and hard to suppress. So
add a bootstrap strlen function and redirect to it right from the
start. This fn only replaces the strlen in ld.so; the "normal"
redirect mechanism still replaces the strlen that glibc supplies.
This commit finally (!) makes memcheck behave sanely on ppc32.
Julian Seward [Thu, 18 Aug 2005 11:50:43 +0000 (11:50 +0000)]
Add tested but unused code just in case it is useful at some point in
the future: a potentially more memcheck-friendly implementation of
count-leading-zeroes.
Make the nightly script say early on if the results have changed in
the last 24 hours. This saves you from having to scroll down to
determine this when the number of failures is large (eg on PPC).
Fixes for #110657, based on Jakub Jelinek's patch:
- filter out L3 warning messages so they don't break Cachegrind's regtests
- handle lack of mq support gracefully in mq.c
How do you like this: there was no proper description in the manual
of leak error messages, nor any examples. So I added one, and moved
what info there was about leaks out of its separate section, and into
the section describing all the kinds of error message.
Something I realised recently: in C, iterators are much better than
higher-order functions for traversing data structures. The higher-order
approach is too clumsy due to the lack of polymorphism and closures; you
have to use void* too much and it is more verbose than it should be.
Hence, I replaced all the uses of HT_first_match() and
HT_apply_to_all_nodes() with equivalent uses of the hashtable iterator.
Also replaced higher-order traversal functions for Memcheck's freed-list
and the thread stacks with iterators. That last change changes the
core/tool interface, so I've increased the version number.
Added new module, m_oset, which provides a generic data structure, OSet,
which is a sorted set with no duplicates. This is derived from
m_skiplist, which it will hopefully replace. The interface has the
following improvements:
- Avoided all mention of how the data structure is implemented in the
interface, so it could be replaced with another data structure without
changing external code.
- Two kinds of comparison: fast -- use the first word of each element
for comparison; slow -- use a custom function. The custom function
compares a key with an element, so non-overlapping interval lists can
be supported easily. m_skiplist only supports the slow variant, and it
makes things almost 2x faster.
- Users pass in malloc() and free() functions, so m_oset.c it doesn't
rely on any particular allocator.
- It has a Destroy() function which will deallocate all the nodes.
- It allows variable-sized nodes.
- No static constructor; I needed the flexibility of being able to
execute arbitrary code in the constructor. This also means no type
internals are exposed.
No part of Valgrind actually uses OSet yet, although I've privately
converted several data structures, and so I'm confident that the
interface is basically sound. Some functions may be added later.
The implementation uses AVL trees, and has the following
characteristics:
- Lookup is much faster than for skiplists -- around 3x. This is
because the inner lookup loop is much tighter.
- Insertion and removal is similar speed to skiplists, maybe a little
slower, but there's still some fat to be trimmed.
- The code is a bit longer and more complex than the skiplist code.
This was intended to replace the need for the VgHashTable type. But my
experiments have shown that VgHashTable is really fast, faster than both
AVL trees and skiplists in all but extreme cases (eg. if the hashtable
becomes way too full): insertion takes constant time, because you always
prepend to chains; lookup depends on chain length, but the inner loop
is so tight that you need about 20 elements per chain before it gets
worse than the AVL tree; removal is similar to lookup. And because
insertion uses prepending, any locality in accesses will help things. If
VgHashTable had its interface cleaned up to look like OSet's, and was made
to auto-resize when it got too full, it might be a better OSet (although
it's not sorted).
So, it's currently unclear exactly how the AVL tree OSet will be used.
The skiplist could be converted to the new interface (I have a 90%
complete version which I used in the comparison experiments). If
VgHashTable was converted to the same interface (or as close as
possible) it would make direct comparison of important places (eg.
Memcheck's malloc_lists) simple.
Changed many, but not all, of the VgHashNode* parameters and return
types in m_hashtable.c to void*. This requires no changes to code
already using VgHashTables, but it allows some previously-required casts
to be removed. I also changed Memcheck and Massif by removing some of
these now-unnecessary casts.
projects / thirdparty / valgrind.git / log
