diff options
author | Sean Anderson <seanga2@gmail.com> | 2022-03-23 14:04:49 -0400 |
---|---|---|
committer | Tom Rini <trini@konsulko.com> | 2022-04-11 10:00:30 -0400 |
commit | bdaeea1b6863b0ec80f2d4bc15d50b8d16efa708 (patch) | |
tree | a9a68f315eceeabb9477bb58b8726e307dc2c99c /test | |
parent | fba0882bcdfd919727ee9ee8523ef3156daab507 (diff) | |
download | u-boot-bdaeea1b6863b0ec80f2d4bc15d50b8d16efa708.tar.gz u-boot-bdaeea1b6863b0ec80f2d4bc15d50b8d16efa708.tar.bz2 u-boot-bdaeea1b6863b0ec80f2d4bc15d50b8d16efa708.zip |
malloc: Annotate allocator for valgrind
This annotates malloc and friends so that valgrind can track the heap. To
do this, we need to follow a few rules:
* Call VALGRIND_MALLOCLIKE_BLOCK whenever we malloc something
* Call VALGRIND_FREELIKE_BLOCK whenever we free something (generally after
we have done our bookkeeping)
* Call VALGRIND_RESIZEINPLACE_BLOCK whenever we change the size of an
allocation. We don't record the original request size of a block, and
neither does valgrind. For this reason, we pretend that the old size of
the allocation was for 0 bytes. This marks the whole allocaton as
undefined, so in order to mark all bits correctly, we must make the whole
new allocation defined with VALGRIND_MAKE_MEM_DEFINED. This may cause us
to miss some invalid reads, but there is no way to detect these without
recording the original size of the allocation.
In addition to the above, dlmalloc itself tends to make a lot of accesses
which we know are safe, but which would be unsafe outside of dlmalloc. For
this reason, we provide a suppression file which ignores errors ocurring in
dlmalloc.c
Signed-off-by: Sean Anderson <seanga2@gmail.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Diffstat (limited to 'test')
0 files changed, 0 insertions, 0 deletions