On Fri, Jun 6, 2014 at 8:29 PM, Yuri Gribov <tetra2...@gmail.com> wrote: > Dmitry, > >> I propose to add -fsanitize=kernel-address when the first patch is >> committed. Now it will just enable "-fsanitize=address >> -asan-instrumentation-with-call-threshold=-1" internally. But later we >> will be able to change instrumentation for kernel under the hood w/o >> disturbing users. > > Yup, sounds right. Note that this will (unfortunately) be > --param asan-instrumentation-with-call-threshold=0 (not -1) > because GCC developers don't want to allow negative parameters.
If it all happens under the covers of -fsanitize=kernel-address, it does not matter much, right? >> As for __kasan vs __asan prefixes, I don't care too much. >> __asan will work for us. > > Ok. Or we could throw in a some __attribute__((alias))'es. We can (and probably will) throw them temporary during transition. But I don't want to leave them forever. It looks ugly. >> Also, does gcc asan pass emit ctors into every translation unit? It >> was not working for us a year ago in kernel. Do you plan to disable >> them in kernel instrumentation mode? > > We had some discussion with Andrey but haven't yet fleshed anything out. > For now we will disable them with --param asan-globals=0. Then this is another reason to introduce -fsanitize=kernel-address earlier rather than later. -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and stop receiving emails from it, send an email to address-sanitizer+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
