On Tue, May 28, 2024 at 1:38 PM Alexander Monakov <amona...@ispras.ru> wrote: > > > 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).
OK, I see. > > > 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? Well, sure - but of course I think our plugin API is broken and I rather have such feature in-tree. It possibly makes sense for _valgrind_ to host such a plugin, not so much for GCC itself (because then, just build it in-tree). As said, I'm nervous about libgcc, everything else is OK I think (didn't look into the pass in detail yet, but I trust you here). Richard. > Thanks. > Alexander
