because it was always being set to VG_MIN_ALLOC_SZB, and so was just one
more thing to get wrong, as well as exposing VG_MIN_ALLOC_SZB to more places
than necessary.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@3340
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
Fixed demangler bug -- it was relying on glibc for some functions. This
triggered an incredibly obscure bug in my experimental skin -- memcpy() was
called within the demangler at (about?) the same time as the dynamic linker was
fiddling with the memcpy() entry, which caused one word of memory (probably
some counter in the dynamic linker) to be incremented, which my skin didn't
like.
So I removed all (AFAICT) of the demangler's dependencies on glibc. This
required adding macros for memset, memcpy, strlen, strcmp..., to replace them
with their VG_(...) version. The only #includes now are to .h files that are
part of Valgrind.
Also required #defining "size_t" as "Int".
Also required adding VG_(memcmp)() to vg_mylibc.c.
Also removed the "-1 == EOF" part of the compile-time test in safe-ctype.h
that checks the character set is ASCII. This was to remove the dependency
on stdio.h. Slightly dodgy, but should be ok I think/hope.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1436
from core error ones:
- Split up VG_(panic) into VG_(core_panic) and VG_(skin_panic)
- Likewise, split vg_assert into vg_assert and sk_assert
- Added a new need string: `bug_reports_to'
- Removed VG_(skin_error) which was a previous wussy attempt at this change.
This removed the need for the hacky redeclaration of VG_(skin_error) in
vg_profile.c, which is good.
At the moment, Julian and Nick's email addresses are hard-coded into each skin
individually, rather than using a #define in vg_skin.h, because that didn't
feel quite right to me... jseward@acm.org is still done with a #define for
core errors, though.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1164
