> From: <exactl...@ispras.ru>
> Date: Tue, 24 Oct 2023 17:11:24 +0300

> From: Daniil Frolov <exactl...@ispras.ru>
> 
> PR 66487 is asking to provide sanitizer-like detection for C++ object lifetime
> violations that are worked around with -fno-lifetime-dse in Firefox, LLVM,
> OpenJade.
> 
> The discussion in the PR was centered around extending MSan, but MSan was not
> ported to GCC (and requires rebuilding everything with instrumentation).
> 
> Instead, allow Valgrind to see lifetime boundaries by emitting client requests
> along *this = { CLOBBER }.  The client request marks the "clobbered" memory as
> undefined for Valgrind; clobbering assignments mark the beginning of ctor and
> end of dtor execution for C++ objects.  Hence, attempts to read object storage
> after the destructor, or "pre-initialize" its fields prior to the constructor
> will be caught.

A long time ago, I hacked the first version of
valgrind-testing support into gcc and I think yours is a
great idea!

A natural follow-up then would be making
-fvalgrind-emit-annotations the default when building gcc
*and* --enable-checking=valgrind is in effect (i.e. not just
expanding the in-source annotations but the explicit testing
mode).  No need to cram it into the first version though.

Also, a preprocessor macro when -fvalgrind-emit-annotations
is in effect, may help dealing with quirky corner cases.

I agree with Arsen that if no valgrind headers are found,
just don't build __valgrind_make_mem_undefined and let its
absense be a linker error rather than trapping in
__valgrind_make_mem_undefined.

I think building libgcc __valgrind_make_mem_undefined should
actually be the *default* when valgrind headers are found,
i.e. in absense of --disable-valgrind-annotations.

A hard configure-time error is suitable when an
--enable-valgrind-annotations is explicitly specified in the
absence of valgrind headers.

BTW, if you use AS_IF, beware of its quirks.  See end of
this email-thread with conclusion when libstdc++ was hit:
https://gcc.gnu.org/pipermail/libstdc++/2023-June/056113.html

brgds, H-P

Reply via email to