On Tue, 28 May 2024, Richard Biener wrote:
> > I am a bit confused what you mean by "cheaper". Could it be that we are not > > on the same page regarding the machine code behind client requests? > > Probably "cheaper" in register usage. But it doesn't matter considering that execution under Valgrind is about 40x slower than native. The intended use is that the project is rebuilt with this instrumentation, run under Valgrind, then discarded. Here's an argument against inlining: it makes breakpointing on the helper possible. And it may be actually necessary. > I also wondered if valgrind is happy with these when applied to stack space > allocated in the caller? Is there means to verify valgrind picks them up > appropriately (as opposed to simply ignore them)? Yes, it works. Exercising this scenario under gcc.dg does not seem easy, though. > No idea ;) But the same argument applies when libgcc from newer compilers > suddenly change that "ABI" because the valgrind version built against changes? This was raised previously with Jakub. I find it implausible that Valgrind folks will make incompatible changes to the client request ABI (they know to keep old requests working when ehnancing the interface). > > What about linking a new library with that helper? > > I guess that would work for me (a static library, that is). Ideally valgrind > itself would provide it so it's clear its tied to the valgrind version rather > than to a GCC version. How about packaging all of this separately as a plugin? Thanks. Alexander
