neater. Also remove some dodgy CFLAGS+= lines.
I had to change the expected output of pth_once.c, because the change has
altered the order of the (non-deterministic) output.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@2825
- 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
