[llvm-commits] AddressSanitizer, first patch

[Chandler Carruth]

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


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.com wiki,
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.

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/a372fe35/attachment.html>