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.

Reply via email to