On Fri, 8 Dec 2023, Jakub Jelinek wrote:
> Does VALGRIND_MAKE_MEM_UNDEFINED macro ever change onarches once implemented > there? It seems Valgrind folks take binary compatibility seriously, so that sounds unlikely. > Wouldn't this be better done by emitting the sequence inline? > Even if it is done in libgcc, it is part of ABI. I'd rather keep it as simple as possible. We could drop the libgcc parts, users can drop in the wrapper as explained in the manual. > So, basically add a new optab, valgrind_request, where each target would > define_insn whatever is needed (it will need to be a single pattern, it > can't be split among multiple) and sorry on -fvalgrind-annotations if the > optab is not defined. There are going to be complications since the request needs a descriptor structure (on the stack), plus it needs more effort on the GCC side than Valgrind side (when Valgrind is ported to a new target). I'd rather not go that way. > Advantage would be that --enable-valgrind-interop nor building against > valgrind headers is not needed. Alternatively, how about synthesizing an auxiliary translation unit with the wrapper from the driver for -fvalgrind-annotations? > In your version, did the new function go just to libgcc.a or to > libgcc_s.so.1? It participates in libgcc_s link, but it's not listed in the version script, so it's not exported from libgcc_s (and -gc-sections should eliminate it). Alexander
