On Fri, Dec 06, 2013 at 01:09:29PM +0100, Jakub Jelinek wrote: > On Fri, Dec 06, 2013 at 03:28:50PM +0400, Yury Gribov wrote: > > Hi all, > > > > GCC version of Asan currently lacks options for detailed control > > over code instrumentation. These are not usually necessary but for > > embedded systems with scarce system resources Asan memory overhead > > of 2x-3x may often be unacceptable. > > > > It seems that LLVM provides some options to allow programmer select > > which part of his code/memory he's interested in: > > * -asan-instrument-reads > > * -asan-instrument-writes > > * -asan-memintrin > > * -asan-stack > > * -asan-globals > > * -blacklist > > I'm strongly against the blacklist, that is not the way things are done in > GCC, you have corresponding attribute to mark functions you don't want to > instrument, people can macroize that with > __typeof (symbol) symbol __attribute__((__no_sanitize_address__)); > But in any case, you mark it in the code rather than adding externally > some symbol list. > > For others, perhaps, the question is what options to use for them, because > -asan-* options are clearly unacceptable. Perhaps best might be > --param asan-instrument-reads=0 and similar. Note I'd prefer not to > implement ABI changing options, like making red zone size, or shadow > shift or shadow base etc. variable, it is enough that libasan, etc. doesn't > have a stable ABI in between major GCC versions, we don't want to people > have issues with library X compiled with GCC 4.9 with one asan ABI and > another with a different one.
On second though besides of decreasing of code size there is no reason to complicate compilation for these features. A more flexible way is add environment variable that will disable these at runtime.