name the events, rather than just number them, which makes it a
lot easier to use
* Based on that, fill in some fast-path cases
{LOAD,STORE}V{4,2,1}. The assembly code looks about the same
length as it did before, on x86. Fast-path cases for the
stack have yet to be done.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3538
there is a better way to handle the 'pessimising cast' family of
operations in such a way that Vex's back-end instruction selectors can
generate better code than they do now, with less verbosity and general
confusingness in the insn selectors.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3536
32- and 64-bit targets, little- and big-endian. It does more or less
work on x86 as-is, although is unusably slow since I have knocked out
all the fast-path cases and am concentrating on getting the baseline
functionality correct. The fast cases will go back in in due course.
The fundamental idea is to retain the old 2-level indexing for speed,
even on a 64-bit target. Since that's clearly unviable on a 64-bit
target, the primary map handles only first N gigabytes of address
space (probably to be set to 16, 32 or 64G). Addresses above that are
handled slowly using an auxiliary primary map which explicitly lists
(base, &-of-secondary-map) pairs. The goal is to have the
address-space-manager try and put everything below the 16/32/64G
boundary, so we hit the fast cases almost all the time.
Performance of the 32-bit case should be unaffected since the fast map
will always cover at least the lowest 4G of address space.
There are many word-size and endianness cleanups.
Jeremy's distinguished-map space-compression scheme is retained, in
modified form, as it is simple and seems effective at reducing
Memcheck's space use.
Note this is all subject to rapid change.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3535
because the redirect syms are set up only after the initial read of
/proc/self/maps and by then ld-linux.so.2 is already aboard. Fixing
this properly requires fixing the address space management stuff
properly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3534
core.h and tool.h into pub_core_errormgr.h and pub_tool_errormgr.h. All
just to improve general modularity.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3532
string explaining more detail if the assertion fails (eg. the value of the
bogus variable) using printf-style format arguments.
One consequence of this is that you can do something like
vg_assert2(0, "bad bad bad");
instead of calling VG_(core_panic). The advantage of the new approach is
that it shows the file/function/line info for the failing code, whereas
VG_(core_panic)() does not.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3528
controlled (rounding user malloc requests up to a multiple of 4).
Subsequent changes to memcheck made it more or less pointless, it is a
time waster in the malloc/free path, and nobody ever used it AFAIK.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3522
make their role clearer and their behaviour more consistent with the fields
describing the client's stack. Also made the code in x86-linux/syscalls.c
and amd64-linux/syscalls.c more word-size-independent, which is not strictly
necessary but makes the code similarities between the two files more
obvious.
One consequence of this is that Valgrind's stack on AMD64 is now 16384 * 8
bytes, rather than 16384 * 4 bytes.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3520
greater than MIN_LINE_SIZE equal to MIN_LINE_SIZE. This makes the
x86/fpu-28-108 regression test pass.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3518
- removed "stack_base" which wasn't used in any meaningful way
- added "client_" prefix to make it clear they concern the client's stack
- renamed "stack_size" as "client_stack_szB" to make the units clear
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3516
command-line flag (--max-stackframe=number), rather than hardwiring it
to 2000000. This is helpful for dealing with unruly Fortran programs
which want to allocate large arrays on the stack.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3512
idea is the same -- write functions with special names encoding
sonames and fn names, and have the redir mechanism notice them.
However the way the functions are generated is significantly changed:
* The name mangling scheme has been replaced with one which is just about
simple enough not to need a preprocessing phase. Hence
vg_replace_malloc.c.base is replaced by vg_replace_malloc.c, and
the preprocessor disappears. The demangler in vg_symtab2.c changes
accordingly.
* Kill off the horrendous LIBALIAS macro. In return we have to
enumerate all the redirections longhand, but this is not a big deal.
* Remove use of the GNUisms "attribute alias" and "attribute
protected".
* Remove the hardwired assumption that any C++ new/new[]/etc symbols
we might want to intercept are mangled in GNU style.
* Add more comments.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3510
seemed to completely confuse the compiler and it was generating
nonsense code to get the address of the replacement routines.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3495
don't put a dependency between the install target and $(BUILT_SOURCES)
so doing a straight install doesn't work.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3494
long sequences of x86 insns with IR optimisation disabled, so the
tag-checking crap doesn't get knocked out like it usually does.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3492
