[llvm-commits] AddressSanitizer, first patch

[Kostya Serebryany]

On Thu, Sep 15, 2011 at 2:08 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Thu, Sep 15, 2011 at 1:31 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> Hi,
>>
>> I haven't heard any more comments.
>> Eric Christopher confirmed that the only concern is having the
>> instrumentation pass w/o the run-time library.
>> I do want to contribute run-time as well.
>> How do we proceed?
>>
>
> I'd like to point out a potential way to separate these two issues, and
> address some other concerns.
>
> I think it would be useful for the instrumentation to also emit stubs for
> each run-time library call that it emits calls to. These stubs should bo
> no-ops, and should have the proper linkage to be replaced the moment the
> run-time is linked in (regardless of how), but should allow instrumented
> code to be linked or loaded even without the runtime.
>
> Consider the case of a python module. You may *need* a python interpreter
> you don't control and can't rebuild to load the object files and still
> "work", even if the instrumentation no longer is able to report bugs.
>
> I think adding this would ease the introduction of the instrumentation
> pass, and would help in situations even if we presume that the runtime is
> essentially "always available".
>

This will not work. To make it work, some non-trivial changes will have to
be done and even then I am not sure.
Even if we stub-out all run-time calls (this patch introduces only one, but
the full asan has three more), we will still have the instrumentation code
which is accessing the shadow memory.
W/o the run-time library that actually maps this memory at startup the
program will SEGV immediately.


>
>
> Of course, I'd still like to address the issue of if and how the runtime
> could be part of LLVM...
>
>
>> I'd like to have the run-time available as part of LLVM, and I would agree
>> on any reasonable way of doing so in the following order of preference:
>>   - use svn:externals to point to the existing repository at
>> http://code.google.com/p/address-sanitizer/source/checkout
>>
>
> This doesn't seem very workable... See below.
>
>
>>   - copy the code to LLVM repository and periodically take the fresh
>> versions from c.g.c repository.
>>   - use the LLVM repository as the primary repository (here I am concerned
>> with the tool chain: we are too used to the features provided by c.g.c.)
>>
>
> Just to be clear, the last two options could actually take two different
> forms each:
>
> By "LLVM repository", that could either be an LLVM subproject, which
> essentially has its own repository hosted by the LLVM project.
>
> This could potentially be used in conjunction with the code.google.comwiki, issue tracking, and other infrastructure. It would just mean the svn
> would live on a different server, and there would be 'foo.llvm.org'
> addresses that redirect to the code.google.com pages.
>

I would prefer an LLVM subproject.

--kcc


>
> Also by "LLVM repository", it could mean a 'runtime/asan' directory inside
> the primary LLVM codebase.
>
> This would likely impose several other restrictions:
> - Use the LLVM bug tracker, documentation, and website
> - Use the LLVM coding conventions throughout
>
>
> I'm not trying to speak to which solution is best, just hoping to clarify
> some of the issues better.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20110915/61d4c3cc/attachment.html>