https://bugs.kde.org/show_bug.cgi?id=522533
Mark Wielaard <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] Ever confirmed|0 |1 Status|REPORTED |CONFIRMED --- Comment #5 from Mark Wielaard <[email protected]> --- (In reply to Sam James from comment #4) > (In reply to Sam James from comment #3) > > Jan rightly points out [0] that it may not make sense to build Valgrind > > itself w/ -Wa,-O2 but similar issues happen when Valgrind itself wasn't but > > it is executing a binary that was (sorry, should've said this earlier, I'd > > said it on IRC last night): > > Oh, interesting.. the function in systemd has this: > > #if HAVE_VALGRIND_VALGRIND_H > _destructor_ static void cleanup_pools(void) { > /* Be nice to valgrind */ > if (RUNNING_ON_VALGRIND) > hashmap_trim_pools(); > } > #endif Right, the VALGRIND macros are used both my applications with valgrind support and by the valgrind vg_preload libraries. This explains why you saw it just by rebuilding an application and not just by rebuilding valgrind itself. > so maybe we need to do something in valgrind.h instead (note that it is > unfortunately vendored in many projects..). Yes, we don't control whether the VALGRIND markers are build with or without optimizations since they are part of valgrind.h (which as you point out is vendored in a lot of projects). So we need some solution that works even with optimizations and for the unchanged assembly sequence (since we cannot change it now that various applications use that assembly sequence in (their copy of) valgrind.h as is). -- You are receiving this mail because: You are watching all bug changes.
