From: Paul F. <pj...@wa...> - 2024-08-26 19:27:43
|
On 26-08-24 14:29, Mark Wielaard wrote: > Hi, I also agree that this sounds very interesting. I quickly skimmed over the paper. I haven't had time to look at the code yet. Do you have any feeling as to how many people would make use of this? >> The patch is designed to be off by default. The user can start scanning >> for divisions using --variable-latency-errors=yes on the command line, >> VALGRIND_CLO_CHANGE("--variable-latency-errors=yes") from the program >> under test, or, easiest to use, a new environment variable >> VALGRIND_BESTEFFORT_VARIABLE_LATENCY_ERRORS=yes. > > The environment variable trick is nice. I wonder if we can generalize > that. I'm not keen on more environment variables. We already have 3 mechanisms for passing options (command line, .valgrindrc and VALGRIND_OPTS). There's plenty to confuse users already (which options are command line only, what is the precedence between .valgrindrs and VALGRIND_OPTS). It would just confuse matters to have more environment variables. Using VALGRIND_OPTS is clunky but I think that we should stick to that. Looking at the competition, Address Sanitizer just uses ASAN_OPTIONS. A+ Paul |