[LLVMdev] LLVM-based address sanity checker

[Chandler Carruth]

Any updates on this?

In particular, I'd like to see concrete patches proposed for review and
inclusion into LLVM. I think having actual patches on the table and under
review will help a great deal. Kostya, let me know if I can help prepare
them. A few general comments as well inline...

On Tue, Jul 26, 2011 at 1:57 AM, Kostya Serebryany <kcc at google.com> wrote:

> On Tue, Jul 26, 2011 at 10:20 AM, Chris Lattner <clattner at apple.com>wrote:
>
>>
>> On Jun 21, 2011, at 8:05 AM, Kostya Serebryany wrote:
>>
>> > Hi,
>> > What would be our next steps in getting ASan into the LLVM trunk?
>> > I'd like to do it in two steps, first for the LLVM part with minimal
>> tests and then for the run-time library and all tests.
>> > The current ASan's source repository will probably stay the primary home
>> for the run-time library and tests as we plan to use it in non-LLVM
>> environments.
>> >
>>
>> Hi Kostya,
>>
>> I haven't had a chance to look at your patch yet, I'm backed up on "big
>> patches".  Did you see my review of the safecode patch here?
>>
>> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110718/124515.html
>>
>> I expect to have similar concerns and suggestions for your patch,
>>
>
> Hi Chris,
>
> Thanks for the reply.
> Indeed, some of your comments to safecode patch apply here.
>
> Codingstyle: I'll try to cleanup as much as I can today.
> Do you have any lint-like tool that checks for llvm coding style (similar
> to cpplint <http://google-styleguide.googlecode.com/svn/trunk/cpplint/>)?
>

I don't know of any effective ones. Kostya, maybe you can send the code by
myself and/or Nick to help walk through it for style issues?

Documentation: everything is in the wiki. The main pages are:
> http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer
> http://code.google.com/p/address-sanitizer/wiki/AddressSanitizerAlgorithm
>

It would be good to have these written up in HTML for easy inclusion in the
existing LLVM documentation tree. This tree is checked in along side the
code itself. However, contributing snapshots of the documentation from the
wiki page could likely occur in follow-up patches. Alternatively, maybe
Chris would be OK linking to these wiki pages from the primary LLVM
documentation.


> "who is going to maintain": my team at Google (in particular, myself and
> Alexander, in CC) are highly motivated to keep this working.
> "Do you have particular clients": the Chromium project is a very active<http://blog.chromium.org/2011/06/testing-chromium-addresssanitizer-fast.html>client.


For reference, myself and others on my team at Google are working actively
with Clang and LLVM and would be able to maintain, fix bugs, and update
this. We also have a *very* large base of users that would be interested in
the functionality.


> "The work can be decomposed into small and incremental pieces":
>    the LLVM part<http://code.google.com/p/address-sanitizer/source/browse/trunk/llvm/AddressSanitizer.cpp>is just 1000 LOC. If you still like it to be decomposed, we can do it in 3
> parts: a) general instrumentation, b) redzones for stack, c) redzones for
> globals.
>

I think breaking up the LLVM part would be very helpful. Can you break out
the first part, and after a style cleanup mail the attached patch? Then the
review for that can overlap with preparing the other 2 parts.


How do you plan to test this? It's important that there are regression tests
in the LLVM suite that exercise the functionality independent of any runtime
so that other developers can catch regressions. Also, unittests in the LLVM
unittest tree would be nice as well.


Have you written a Clang patch to turn this functionality on and off?
Looking at the wiki documentation shows one thing that gives me pause:
you're using the -mllvm flag in Clang to directly pass options down to the
LLVM layer. Also, it indicates the asan functionality defaults to on.

Ideally all of this functionality would default to off, and be enabled via
'-fasan' or even better '-faddress-sanitizer' in Clang. That would match the
behavior of '-fcatch-undefined-behavior', '-fmudflap', etc. If you want to
expose the more fine grained flags to users that are mentioned on the wiki
page, they could also have '-f...' Clang flags, but it seems unlikely that
those are important.


What's your expected plan for the runtime library? Is that something you
would be interested in contributing to the LLVM project proper? If so, I'd
be interested in where Chris thinks that should go... in the LLVM runtimes
tree? In a separate LLVM project?

Anyways, thanks for working on integrating this back into LLVM!
-Chandler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110801/a092dd9c/attachment.html>