Moved the MALLOCLIKE and FREELIKE client requests out of memcheck.h, and into
valgrind.h. Although these requests are not implemented by the core, they can
be implemented by skins that track heap blocks, eg. Memcheck, Annelid, Massif.
This is in preparation for committing Massif to the repository.
I think I managed to make the change in a binary-compatible way. The only
inconvenience for users is that if they have a client program compiled with the
old requests in, Valgrind will abort with an explanatory message that tells
them to recompile. Once they've done that (no changes to their program are
required), it works again.
I even updated the docs.
git-svn-id: svn://svn.valgrind.org/valgrind/trunk@1881 a5019735-40e9-0310-863c-91ae7b9d1cf9
diff --git a/include/valgrind.h b/include/valgrind.h
index 1733819..a1711fd 100644
--- a/include/valgrind.h
+++ b/include/valgrind.h
@@ -132,6 +132,9 @@
/* Some request codes. There are many more of these, but most are not
exposed to end-user view. These are the public ones, all of the
form 0x1000 + small_number.
+
+ Core ones are in the range 0x00000000--0x0000ffff. The non-public ones
+ start at 0x2000.
*/
#define VG_USERREQ_SKIN_BASE(a,b) \
@@ -154,7 +157,11 @@
Valgrind's output to /dev/null and still count errors. */
VG_USERREQ__COUNT_ERRORS = 0x1201,
- VG_USERREQ__FINAL_DUMMY_CLIENT_REQUEST
+ /* These are useful and can be interpreted by any skin that tracks
+ malloc() et al, by using vg_replace_malloc.c. */
+ VG_USERREQ__MALLOCLIKE_BLOCK = 0x1301,
+ VG_USERREQ__FREELIKE_BLOCK = 0x1302,
+
} Vg_ClientRequest;
@@ -231,4 +238,42 @@
_qyy_res; \
})
+/* Mark a block of memory as having been allocated by a malloc()-like
+ function. `addr' is the start of the usable block (ie. after any
+ redzone) `rzB' is redzone size if the allocator can apply redzones;
+ use '0' if not. Adding redzones makes it more likely Valgrind will spot
+ block overruns. `is_zeroed' indicates if the memory is zeroed, as it is
+ for calloc(). Put it immediately after the point where a block is
+ allocated.
+
+ If you're allocating memory via superblocks, and then handing out small
+ chunks of each superblock, if you don't have redzones on your small
+ blocks, it's worth marking the superblock with VALGRIND_MAKE_NOACCESS
+ when it's created, so that block overruns are detected. But if you can
+ put redzones on, it's probably better to not do this, so that messages
+ for small overruns are described in terms of the small block rather than
+ the superblock (but if you have a big overrun that skips over a redzone,
+ you could miss an error this way). See memcheck/tests/custom_alloc.c
+ for an example.
+
+ Nb: block must be freed via a free()-like function specified
+ with VALGRIND_FREELIKE_BLOCK or mismatch errors will occur. */
+#define VALGRIND_MALLOCLIKE_BLOCK(addr, sizeB, rzB, is_zeroed) \
+ {unsigned int _qzz_res; \
+ VALGRIND_MAGIC_SEQUENCE(_qzz_res, 0, \
+ VG_USERREQ__MALLOCLIKE_BLOCK, \
+ addr, sizeB, rzB, is_zeroed); \
+ }
+
+/* Mark a block of memory as having been freed by a free()-like function.
+ `rzB' is redzone size; it must match that given to
+ VALGRIND_MALLOCLIKE_BLOCK. Memory not freed will be detected by the leak
+ checker. Put it immediately after the point where the block is freed. */
+#define VALGRIND_FREELIKE_BLOCK(addr, rzB) \
+ {unsigned int _qzz_res; \
+ VALGRIND_MAGIC_SEQUENCE(_qzz_res, 0, \
+ VG_USERREQ__FREELIKE_BLOCK, \
+ addr, rzB, 0, 0); \
+ }
+
#endif /* __VALGRIND_H */