<br><br><div class="gmail_quote">On Thu, Sep 15, 2011 at 2:08 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div>On Thu, Sep 15, 2011 at 1:31 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi, <div><br></div><div>I haven't heard any more comments. </div><div>Eric Christopher confirmed that the only concern is having the instrumentation pass w/o the run-time library. </div><div>I do want to contribute run-time as well. </div>
<div>How do we proceed? </div></blockquote><div><br></div></div><div>I'd like to point out a potential way to separate these two issues, and address some other concerns.</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>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".</div></div></blockquote>
<div><br></div><div>This will not work. To make it work, some non-trivial changes will have to be done and even then I am not sure. </div><div>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.</div>
<div>W/o the run-time library that actually maps this memory at startup the program will SEGV immediately.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote"><div><br>
</div><div><br></div><div>Of course, I'd still like to address the issue of if and how the runtime could be part of LLVM...</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>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:</div><div> - use svn:externals to point to the existing repository at <a href="http://code.google.com/p/address-sanitizer/source/checkout" target="_blank">http://code.google.com/p/address-sanitizer/source/checkout</a></div>
</blockquote><div><br></div></div><div>This doesn't seem very workable... See below.</div><div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div> - copy the code to LLVM repository and periodically take the fresh versions from c.g.c repository. </div><div> - 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.)</div>
</blockquote><div><br></div></div><div>Just to be clear, the last two options could actually take two different forms each:</div><div><br></div><div>By "LLVM repository", that could either be an LLVM subproject, which essentially has its own repository hosted by the LLVM project.</div>
<div><br></div><div>This could potentially be used in conjunction with the <a href="http://code.google.com" target="_blank">code.google.com</a> wiki, issue tracking, and other infrastructure. It would just mean the svn would live on a different server, and there would be '<a href="http://foo.llvm.org" target="_blank">foo.llvm.org</a>' addresses that redirect to the <a href="http://code.google.com" target="_blank">code.google.com</a> pages.</div>
</div></blockquote><div><br></div><div>I would prefer an LLVM subproject. </div><div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_quote">
<div><br></div><div>Also by "LLVM repository", it could mean a 'runtime/asan' directory inside the primary LLVM codebase.</div><div><br></div><div>This would likely impose several other restrictions:</div>
<div>- Use the LLVM bug tracker, documentation, and website</div><div>- Use the LLVM coding conventions throughout</div><div><br></div><div><br></div><div>I'm not trying to speak to which solution is best, just hoping to clarify some of the issues better.</div>
</div>
</blockquote></div><br>