https://bugs.kde.org/show_bug.cgi?id=492255
Niels Möller <ni...@lysator.liu.se> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |ni...@lysator.liu.se
--- Comment #5 from Niels Möller <ni...@lysator.liu.se> ---
Hi! I see absolutely no problem with valgrind not supporting msan or asan
executables in any meaningful way.
But it would be very helpful if valgrind rejected unsupported executables with
an error message.
My context is the the GNU Nettle crypto library. When possible, I use valgrind
in my testsuite, to detect side channel leakage due to memory accesses or
branches depending on secret data (which valgrind does very well, also covering
assembly code the C compiler is unaware of). But I can't just use valgrind
whenever it is installed. E.g., in a cross compiling setup, where the testsuite
runs executables under test via binfmt and qemu, I can't use valgrind. That's
why I have a configure test to check if valgrind works on the executables
produced by whatever compiler the user has configured for the build. But then
there's a problem if that configure test hangs forever for certain compiler
configurations.
One could maybe use nm to check for a list of symbols indicating potential
trouble, or use the timeout command to kill the process if it appears to hang,
but since those tools aren't universally available, using them in the configure
script would be a real hassle with additional tests for those tools, fallbacks
if they aren't found, etc.
Is it unreasonable to expect that valgrind terminates with an error message if
passed inputs that it doesn't support? Would it be difficult to implement, at
least for well known classes of unsupported input executables?
--
You are receiving this mail because:
You are watching all bug changes.
