On 5/28/22 4:20 AM, Heinrich Schuchardt wrote:
On 5/27/22 15:25, Sean Anderson wrote:
On 5/27/22 3:14 AM, Heinrich Schuchardt wrote:
On 5/27/22 05:36, Sean Anderson wrote:
This document some additional options which can be used with valgrind, as
Thanks for enhancing this document
nits %s/document/documents/
well as directions for future work. It also fixes up inline literals to actually be inline literals (and not italics). The content of this documentation is primarily adapted from [1].
[1] https://lore.kernel.org/u-boot/57cb4b49-fa30-1194-9ac3-faa53e8033bd@gmail.co...
Signed-off-by: Sean Anderson seanga2@gmail.com
doc/arch/sandbox.rst | 65 +++++++++++++++++++++++++++++++++++++++++--- 1 file changed, 61 insertions(+), 4 deletions(-)
diff --git a/doc/arch/sandbox.rst b/doc/arch/sandbox.rst index e1119492b4..cd5090be71 100644 --- a/doc/arch/sandbox.rst +++ b/doc/arch/sandbox.rst @@ -479,19 +479,76 @@ It is possible to run U-Boot under valgrind to check memory allocations::
valgrind ./u-boot
-For more detailed results, enable `CONFIG_VALGRIND`. There are many false -positives due to `malloc` itself. Suppress these with:: +For more detailed results, enable ``CONFIG_VALGRIND``. There are many false +positives due to ``malloc`` itself. Suppress these with::
What do you mean by 'malloc itself'? Is it the internal implementation of malloc? Or is it the act of calling malloc()?
This paragraph should explain what CONFIG_VALGRIND does:
The sandbox allocates a memory pool via mmap(). U-Boot's internal malloc() and free() work on this memory pool. Custom allocators and deallocators are by default invisible to valgrind. It is CONFIG_VARLGRIND=y that exposes U-Boot's malloc() and free() to valgrind.
If I understand include/valgrind/valgrind.h correctly, it injects placeholder assembler code that valgrind can replace by library calls into valgrind itself when loading the U-Boot binary.
I believe this is correct. I will adapt your above description for v2.
I miss a statement indicating that the sandbox on RISC-V has no valgrind support, yet.
I was not aware of this. The Kconfig should probably be updated.
The U-Boot code does not use VALGRIND_MEMPOOL* macros to indicate which memory pools it manages. Is this the reason for the problems we are facing?
Hello Sean,
thanks for revising the patch.
Will you have a look at the usefulness of VALGRIND_MEMPOOL* for U-Boot?
I don't know if this would address anything. There's still the problem that dlmalloc has to access the red zones.
--Sean