Memcheck is done, but any tool which generates IR helper calls will
need to be similarly adulterated.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5418
- fixed launcher.c to recognise ppc32/64-linux platforms properly
- lots of assembly fixes to handle func descriptors, toc references, 64bit regs.
- fixed var types in vki-ppc64-linux
Now gets as far as VG_(translate), but dies from a case of invalid orig_addr.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5299
which stops glibc falling over when a program requires an executable
stack and glibc has been built to assume that PROT_GROWSDOWN will work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@5041
was in the sigframe module has been moved into the coredump module
where it belongs and things fixed up to compiler again.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4970
the guest extents for the presented translation and also its original
un-redirected guest address. These changes are needed in particular
to make cachegrind's code cache management work properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4943
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4903
out. Instead, print a warning message, continue, and cause any
attempt to trace into a child process to fail with ECHILD.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4861
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4854
changes from r4341 through r4787 inclusive). That branch is now dead.
Please do not commit anything else to it.
For the most part the merge was not troublesome. The main areas of
uncertainty are:
- build system: I had to import by hand Makefile.core-AM_CPPFLAGS.am
and include it in a couple of places. Building etc seems to still
work, but I haven't tried building the documentation.
- syscall wrappers: Following analysis by Greg & Nick, a whole lot of
stuff was moved from -generic to -linux after the branch was created.
I think that is satisfactorily glued back together now.
- Regtests: although this appears to work, no .out files appear, which
is strange, and makes it hard to diagnose regtest failures. In
particular memcheck/tests/x86/scalar.stderr.exp remains in a
conflicted state.
- amd64 is broken (slightly), and ppc32 will be unbuildable. I'll
attend to the former shortly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4789
Also reinstated SF_DEVICE, which is used to ensure we don't try and
leakcheck a page that is mapped from a device. This got lost in the
2.x-to-3.x transition, or some time after.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4538
tool preload modules, which are called vgpreload_<tool>.so. Also
fixed a couple of comments relating to this.
(This need not be merged into 3_0_X.)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4514
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4464
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4415
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4410
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.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4404
being executed then propagate the error from the stat instead of just
return ENOACCES all the time. Fixes bug #110208.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@4330
