Re: [Valgrind-developers] [PATCH] helgrind: add --show-events debug cmdline option

[Paul F. <pj...@wa...>]

On 2026-03-16 14:03, Aaron Merey via Valgrind-developers wrote:
> SHOW_EVENTS in hg_main.c controls whether helgrind prints a trace of > its internal synchronization, threading and memory events. It is > 
set to 0 by default to disable the trace and the only way to enable > it 
is to modify the source code and rebuild valgrind. > > This patch 
replaces SHOW_EVENTS with clo_show_events that is set > using the new 
helgrind cmdline option --show-events. Information > about this option 
is included under helgrind's --help-debug.
Hi Aaron

I assume that there is no noticeable slowdown?

This will be good if ever we want to get any of these traces from a 
user. Saying "run with --show-events=2" is asking a lot less than 
"download valgrind, change a file, build it and then run the test".

Personally I think that it is best to have as many separate trace 
options as is reasonably possible, to keep down noise from long runs.

I quite like what DRD does with

    --trace-barrier=yes|no    Trace all barrier activity [no].
    --trace-cond=yes|no       Trace all condition variable activity [no].
    --trace-fork-join=yes|no  Trace all thread fork/join activity [no].
    --trace-hb=yes|no         Trace ANNOTATE_HAPPENS_BEFORE() etc. [no].
    --trace-mutex=yes|no      Trace all mutex activity [no].
    --trace-rwlock=yes|no     Trace all reader-writer lock activity[no].
    --trace-semaphore=yes|no  Trace all semaphore activity [no].

If you just have one global knob like -v then there is no way to turn 
things off (other than heavy use of awk/grep/sed etc). With multiple 
switches you can always add more. I'm not suggesting that you break up 
the Helgrind output like this - the DRD options reflect the DRD flow.

In the future we might want to do the same with

#define TRACE_PTH_FNS 0
#define TRACE_QT4_FNS 0
#define TRACE_GNAT_FNS 0

A+

Paul