- Moved all the insn_* tests into x86/ subdirectories. What are the chances of
me getting this right on the first attempt?
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2809
- Rewrote tests/cputest.c so that it can apply to different kinds of
processors. The idea being that any arch-specific tests have a cpu_test:
label in their .vgtest file, so they'll only get executed if the right
machine is being used.
- Rewrote a bunch of .vgtest files accordingly.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2802
of using an assembly hack to find the stack pointer at startup, we find it from
argv. It's much simpler, avoids linking games, is platform independent, and
works on PPC.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2782
Valgrind itself (the files ume.c, ume_entry.c and jmp_with_stack.c). Thus,
we are using Memcheck to check these files in a unit test setting.
I hope to do unit self-testing for many more parts of Valgrind, eventually all
the bits that can be pulled out into any kind of sensible stand-alone form.
Doing so achieves two things:
a) it introduces unit testing into our framework (a serious shortcoming at the
moment)
b) it lets us use Valgrind (esp. Memcheck) on itself, to some extent
This should help reliability. This first unit self-test isn't very exhaustive,
but it's a start.
Note that this involves something like bootstrapping, in that we are checking
parts of a Valgrind build with itself. I don't think this will be a problem,
since we (at least, I do) tend to only run the regtests when we think the
Valgrind build is ok.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2760
signal handler present -- previously, Valgrind would abort unnecessarily on
this case.
Added a regression test for it.
MERGE TO STABLE
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2743
lots of the details changed. Made the following generalisations:
- Recast everything to be entirely terms of bytes, instead of a mixture
of (32-bit) words and bytes. This is a bit easier to understand, and
made the following generalisations possible...
- Almost 64-bit clean; no longer assuming 32-bit words/pointers. Only
(I think) non-64-bit clean part is that VG_(malloc)() et al take an
Int as the size arg, and size_t is 64-bits on 64-bit machines.
- Made the alignment of blocks returned by malloc() et al completely
controlled by a single value, VG_MIN_MALLOC_SZB. (Previously there
were various magic numbers and assumptions about block alignment
scattered throughout.) I tested this, all the regression tests pass
with VG_MIN_MALLOC_SZB of 4, 8, 16, 32, 64. One thing required for
this was to make redzones elastic; the asked-for redzone size is now
the minimum size; it will use bigger ones if necessary to get the
required alignment.
Some other specific changes:
- Made use of types a bit more; ie. actually using the type 'Block',
rather than just having everything as arrays of words, so that should
be a bit safer.
- Removed the a->rz_check field, which was redundant wrt. a->clientmem.
- Fixed up the decision about which list to use so the 4 lists which
weren't ever being used now are -- the problem was that this hasn't
been properly updated when alignment changed from 4 to 8 bytes.
- Added a regression test for memalign() and posix_memalign().
memalign() was aborting if passed a bad alignment argument.
- Added some high-level comments in various places, explaining how the
damn thing works.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2579
(fewer) functions.
Also fixed execve() so that it works better with .in_place.
Also added a regression test for --trace-children=yes (there were none!)
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2577
Problem was that the malloc-replacing tools (memcheck, addrcheck, massif,
helgrind) would assert if a too-big malloc was attempted. Now they return 0 to
the client. I also cleaned up the code handling heap-block-metadata in Massif
and Addrcheck/Memcheck a little.
This exposed a nasty bug in VG_(client_alloc)() which wasn't checking if
find_map_space() was succeeding before attempting an mmap(). Before I added
the check, very big mallocs (eg 2GB) for Addrcheck were overwriting the client
space at address 0 and causing crashes.
Added a regtest to all the affected skins for this.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2462
--logfile-fd --> --log-fd
--logfile --> --log-file
--logsocket --> --log-socket
to be consistent with each other and other options (esp. --input-fd). Also
renamed some related variables. The old names still work, for backwards
compatibility, but they're not documented.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2429
Address 0x%x is not stack'd, malloc'd or free'd
to
Address 0x%x is not stack'd, malloc'd or (recently) free'd
This makes things clearer in some circumstances, particularly when bogusly
accessing heap memory that has been freed, but Memcheck is no longer tracking.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2358
look at whether the eflags are read or written and generate UCode to validate
and/or mark as valid the eflags when necessary.
CCMAIL: 78514-done@bugs.kde.org
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2344
Valgrind's dependency on the dynamic linker for getting started, and
instead takes things into its own hands.
This checkin doesn't add much in the way of new functionality, but it
is the basis for all future work on Valgrind. It allows us much more
flexibility in implementation, and well as increasing the reliability
of Valgrind by protecting it more from its clients.
This patch requires some changes to tools to update them to the changes
in the tool API, but they are straightforward. See the posting "Heads
up: Full Virtualization" on valgrind-developers for a more complete
description of this change and its effects on you.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2118
choosing the longest symbol, choose the longest ignoring any of the libc
junk prefixes like __libc_, __, __GI_*, etc. This makes the symbol
presented to the user in messages and used in *.supp files more consistent
and comprehensible.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2114
