Re: [Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)
Could it be possible to add an option like --heap-up-fill --heap-down-fill (like for stack with malloc), that fills heap memory with a specified values (when entering a function and leave a function)? tl;dr 2 See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html The value zero is the worst possible value to use for such initialization, from the viewpoint of quickly producing better software by discovering and identifying bugs sooner. Using the value zero tends to hide many bugs. A much better value is 0x8181...81. This value is non-zero, odd, negative as a signed integer, a very unlikely floating-point value, very often not a valid pointer value, and instantly recognizable in any dump of memory. It was used to great success as the "core constant" (the value of uninitialized RAM) by the Michigan Terminal System for IBM 360/67 and successors, from the early 1970s (50 years ago!) until the demise of MTS around 2000. ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] RFC: proposal to remove user annotation from `cg_annotate`
Hi,
I recently rewrote `cg_annotate`, `cg_diff`, and `cg_merge` in Python. The
old versions were written in Perl, Perl, and C, respectively. The new
versions are much nicer and easier to modify, and I have various ideas for
improving `cg_annotate`. This email is about one of those ideas.
A typical way to invoke `cg_annotate` is like this:
> cg_annotate cachegrind.out.12345
This implies `--auto=yes`, which requests line-by-line "auto-annotation" of
source files. I.e. `cg_annotate` will automatically annotate all files in
the profile that meet the significance threshold.
It's also possible to do something like this:
> cg_annotate --auto=no cachegrind.out.12345 a.c b.c
Which instead requests "user annotation" of the files `a.c` and `b.c`.
My thesis is that auto-annotation suffices in practice for all reasonable
use cases, and that user annotation is unnecessary and can be removed.
When I first wrote `cg_annotate` in 2002, only user annotation was
implemented. Shortly after, I added the `--auto={yes,no}` option. Since
then I've never used user annotation, and I suspect nobody else has either.
User annotation is ok when dealing with tiny programs, but as soon as you
are profiling a program with more than a handful of source files it becomes
impractical.
The only possible use cases I can think of for user annotation are as
follows.
- If you want to see a particular file(s) annotated but you don't want
to see any others, then you can use user annotation in combination with
`--auto=no`. But it's trivial to search through the output for the
particular file, so this doesn't seem important.
- If the path to a file is somehow really messed up in the debug info,
it might be possible that auto-annotation would fail to find it, but user
annotation could find it, possibly in combination with `-I`. But this seems
unlikely. Some basic testing shows that gcc, clang and rustc all default to
using full paths in debug info. gcc supports `-fdebug-prefix-map` but that
seems to mostly be used for changing full paths to relative paths, which
will still work fine.
Removing user annotation would (a) simplify the code and docs, and (b)
enable the possibility of moving the merge functionality from `cg_merge`
into `cg_annotate`, by allowing the user to specify multiple cachegrind.out
files as input.
So: is anybody using user annotation? Does anybody see any problems with
this proposal?
Thanks.
Nick
___
Valgrind-users mailing list
Valgrind-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-users
Re: [Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)
On 28-03-23 11:40, Julien Allali wrote: Hi, Sometimes, valgrind detects error like "Conditional jump or move depends" or "Use of uninitialized value" related to a variable in heap. When using with gdb (--vgdb-error=1), a newbie (i.e. my students) can have difficulties to understand as the value stored is 0 (because there was zeros in heap, not because we set 0 to the variable). Could it be possible to add an option like --heap-up-fill --heap-down-fill (like for stack with malloc), that fills heap memory with a specified values (when entering a function and leave a function)? Would it be complicated to implement? Hi tl;dr I recommend using the vgdb monitor commands, they show what memcheck considers initialized or not. You just have to type something like "memcheck monitor xb sizeof(var)" tl;dr 2 See https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2723r0.html Having a "stack fill" in Valgrind would be very difficult. The problem is identifying exactly what is a stack allocation. Identifying a call to malloc is easy - we have the address of the function. Stack allocation is, roughly, just modifying the stack pointer. The simplest case is where the callee does the stack allocation, on amd64 something like 201910: 55 push %rbp 201911: 48 89 e5mov%rsp,%rbp 201914: 48 83 ec 10 sub$0x10,%rsp where the constant in the last line depends on the amount being allocated. The initial push and move won't be there for optimized builds or if -fomit-frame-pointer is specified. If the compiler is doing RVO then the stack memory will be allocated by the caller. See here https://godbolt.org/z/qasjWGhsK Line 25 in the asm output is where main allocates the space on the stack. Then there is tail-call optimization where there is no call, just a jump to the callee. And then all of the other things that manipulate the stack pointer (alloca, C++ exceptions, signals, setjmp/longjmp). There are a few compiler options that affect stack use. On top of all that each compiler tends to do things differently. I don't know what would be possible with DWARF, but that would only work with debug builds. Going back to my second tl;dr If I compile the godbolt example with clang++-devel -ftrivial-auto-var-init=pattern jfb.cpp -o jfb (that's LLVM 16) then I get 2019a2: be aa 00 00 00 mov$0xaa,%esi 2019a7: ba 00 10 00 00 mov$0x1000,%edx 2019ac: e8 bf 00 00 00 call 201a70 2019b1: 48 8d bd 00 f0 ff fflea-0x1000(%rbp),%rdi 2019b8: e8 73 ff ff ff call 201930 <_Z1fv> which is the caller filling the 4k with 0xaa. A+ Paul ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
[Valgrind-users] about a stack fill option (as for malloc-fill and free-fill)
Hi, Sometimes, valgrind detects error like "Conditional jump or move depends" or "Use of uninitialized value" related to a variable in heap. When using with gdb (--vgdb-error=1), a newbie (i.e. my students) can have difficulties to understand as the value stored is 0 (because there was zeros in heap, not because we set 0 to the variable). Could it be possible to add an option like --heap-up-fill --heap-down-fill (like for stack with malloc), that fills heap memory with a specified values (when entering a function and leave a function)? Would it be complicated to implement? thanks :) Julien. ___ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
