[cfe-commits] adding "-fasan" flag

[Kostya Serebryany]

On Tue, Nov 15, 2011 at 6:40 PM, Eli Friedman <eli.friedman at gmail.com>wrote:

> On Tue, Nov 15, 2011 at 6:22 PM, Kostya Serebryany <kcc at google.com> wrote:
> > Hello,
> > Please review the following patch which adds -fasan (AddressSanitizer)
> flag
> > to clang.
> > (Mostly prepared by Chandler Carruth).
> > The LLVM part of AddressSanitizer has been submitted as r144758.
> > This patch will allow to enable AddressSanitizer from the clang command
> > line.
> > http://codereview.appspot.com/5396042
> > Coming next in separate patches:
> >   - a patch to clang driver to pass linker flags for AddressSanitizer
> > (small)
> >   - the run-time library and the tests (big)
> > Thanks,
> > --kcc
>
> I would prefer -faddress-sanitizer over -fasan; shorter isn't really
> better here.
>

Changing the flag name would sad.
  - The logo of AddressSanitizer is a "Pheasant eating a Bug". "Fasan"
means "Pheasant" in several European languages (also, "Фазан" in Russian).
- Quite a few existing users will have to change their makefiles.



>
> +  if (Args.hasFlag(options::OPT_fasan, options::OPT_fno_asan, false)) {
> +    CmdArgs.push_back("-DADDRESS_SANITIZER=1");
> +  }
>  }
>
> Why would a program need this?  Can a program that's aware of the
> address sanitizer actually do anything usefully different?


To name a few cases:
- replace a custom free list with vanilla malloc/free (to catch more bugs).
This is what webkit does.
http://trac.webkit.org/browser/trunk/Source/WebCore/rendering/RenderArena.cpp
- don't call rlimit or other functions hostile to asan (asan uses a large
chunk of virtual address space)
- increase the default size of thread stacks (asan eats more stack).
- disable code that deliberately accesses unaddressable memory (heap/stack
profilers, leak detectors).




> Also,
> since this define doesn't start with an underscore, it's possible this
> could break a program using the identifier ADDRESS_SANITIZER for
> something else.
>

Quite a few users (including WebKit) already use the current name, it would
be sad to break compatibility.

--kcc


>
> -Eli
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20111115/020ae5da/attachment.html>