<div dir="ltr"><div>BTW, I updated the LangRef patch (D94002). I hope it properly reflects the consensus made so far.</div><div><br></div><div>Juneyoung</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Feb 10, 2021 at 6:14 PM Ralf Jung <<a href="mailto:jung@mpi-sws.org">jung@mpi-sws.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Johannes,<br>
<br>
>> About syntactic constraints - I think it can be helpful for transformations<br>
>> that need to be fully aware of all allocations' lifetimes.<br>
>> For example, AddressSanitizer is currently simply giving up instrumenting<br>
>> things if there is an unknown lifetime usage.<br>
>> If all lifetime intrinsics' pointers are guaranteed to be known<br>
>> expressions, this issue is resolved.<br>
> <br>
> It is "resolved" by disallowing more complex use cases. To hyperbolize<br>
> an analogy: Constant propagation could avoid almost all of its checks/analysis<br>
> if we restrict all expressions to be constant 0.<br>
<br>
> I know this is not the same<br>
> thing but I hope you see where I'm getting at. The proper solution for ASAN<br>
> is to check if it can handle the lifetime markers and not utilize them otherwise.<br>
> If they happen to fall in the proposed syntactic restrictions I assume ASAN<br>
> can already handle them fine anyway, right?<br>
<br>
The fact that ASAN has to give up really gets to the core of the problem here: <br>
if even ASAN, *with full dynamic information*, cannot determine the lifetime of <br>
all alloca -- then clearly there is a gap somewhere in the specification. Every <br>
sufficiently precise specification would exactly determine what ASAN has to do <br>
to be 100% sure about the lifetime of all alloca.<br>
<br>
ASAN *can* determine the lifetime of some sublcass of alloca though, namely <br>
those that satisfy some syntactic restriction. The reason syntactic restrictions <br>
are being proposed is not that anyone likes them; the reason is that *they are <br>
the only proposal on the table* that achieves both:<br>
* Making the lifetime intrinsics actually affect the lifetimes of local variables.<br>
* Making the spec sufficiently precise that something like ASAN (with full <br>
runtime information) can exactly determine the lifetime of all alloca.<br>
<br>
Your alternative proposal of using lifetime markers only to affect the values <br>
stored in alloca does not achieve both of these goals; it gives up on the first <br>
point. That has its pros and cons (as we discussed before, I do not intend to <br>
reopen that discussion), but I hope we can agree that neither your proposal nor <br>
the current LLVM LangRef wording achieve both of the above points?<br>
<br>
Kind regards,<br>
Ralf<br>
<br>
>><br>
>> if (HasUntracedLifetimeIntrinsic) {<br>
>> // If there are lifetime intrinsics which couldn't be traced back to an<br>
>> // alloca, we may not know exactly when a variable enters scope, and<br>
>> // therefore should "fail safe" by not poisoning them.<br>
>> StaticAllocaPoisonCallVec.clear();<br>
>> DynamicAllocaPoisonCallVec.clear();<br>
>> }<br>
>><br>
>> Interestingly, AddressSanitizer is the one that raises an issue as well if<br>
>> the syntactic restriction is enforced.<br>
>> It replaces allocas with __asan_stack_malloc_N, but still leaves its<br>
>> lifetime uses, which breaks the syntactic restriction. A possible solution<br>
>> for this is to simply remove the lifetime calls.<br>
> <br>
> I can't stress this enough, syntactic restrictions are rarely helpful.<br>
> Now we are talking about dropping information because of it. We seem<br>
> to have also fond a non-stack memory user, great.<br>
> <br>
> ~ Johannes<br>
> <br>
> <br>
> </blockquote></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><br></div><font size="1">Juneyoung Lee</font><div><font size="1">Software Foundation Lab, Seoul National University</font></div></div></div></div>