RFC Asan instrumentation control

[Konstantin Serebryany]

On Fri, Dec 6, 2013 at 4:09 PM, Jakub Jelinek <jakub@redhat.com> 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,

I don't like it either. We were forced to implement it by reality.
We never (I hope) use it for asan. But there are cases where we could
not avoid it for tsan and msan.
(imagine third-party code which you can build but can not change,
which has a bug)

> 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,

These are asan-internal and not documented anyway. Mostly for our own
experiments. Don't implement them.

> 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.
>
>         Jakub