<div dir="ltr">Ted,<div><br></div><div>I'm doing an taint-like analysis which requires reasoning across translation units, so I'm doing a phase 1 analysis where I output summary information for each translation unit, and then a phase 2 analysis where I use that summary information to produce bug reports. For instance, if I have the following code:</div><div><br></div><div>// TU.h</div><div><div style="font-size:13px">struct MyStruct {</div><div style="font-size:13px"> int a;</div><div style="font-size:13px"> int b;</div><div style="font-size:13px"> int c;</div><div style="font-size:13px">};</div><div style="font-size:13px">void foo(MyStruct &s);</div><div style="font-size:13px"><br></div><div style="font-size:13px">// TU1.cpp</div><div style="font-size:13px">#include TU.h</div><div style="font-size:13px">void bar() {</div><div style="font-size:13px"> MyStruct t {1, 2, 3};</div><div style="font-size:13px"> foo(t);</div><div style="font-size:13px">}</div><div style="font-size:13px"><br></div><div style="font-size:13px">// TU2.cpp</div><div style="font-size:13px">#include TU.h</div><div style="font-size:13px">void foo(MyStruct &s) {</div><div style="font-size:13px"> ...</div><div style="font-size:13px">}</div></div><div style="font-size:13px"><br></div><div style="font-size:13px">For whatever reason, during the analysis of TU1.cpp t.b's memory might become "tainted". When bar() calls foo(), this taint information is written to a summary text file. In phase 2, at the very beginning of the analysis of TU2.cpp, I load the summary information from phase 1, and observe that a call was made to foo such that s.b should be treated as tainted. So I would like to mark s.b's memory as such.</div><div style="font-size:13px"><br></div><div style="font-size:13px">I don't think that getFieldRegion() is what I'm looking for, because (I believe) it does not update the program state with the construction of the new FieldRegion. </div><div style="font-size:13px"><br></div><div style="font-size:13px">Thanks for your help,</div><div style="font-size:13px"><br></div><div style="font-size:13px">~Scott</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 25, 2015 at 12:49 AM, Ted Kremenek via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Scott,<br>
<br>
Subregion relationships are one-to-many, and they are constructed lazily as memory can be arbitrary re-interpreted when analyzing a path because of casts, etc. If you want to model a binding to ‘MyStruct’, you can construct the FieldRegion yourself using MemRegionManager’s getFieldRegion(), but I don’t know if that’s the solution you are looking for here.<br>
<br>
Can you explain what you are trying to do in more detail? I may be able to help you better with more specifics.<br>
<br>
Ted<br>
<div><div class="h5"><br>
> On Aug 24, 2015, at 1:59 PM, scott constable via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br>
><br>
> Hi All,<br>
><br>
> Suppose I'm analyzing the following code:<br>
><br>
> struct MyStruct {<br>
> int a;<br>
> int b;<br>
> int c;<br>
> };<br>
><br>
> void foo(MyStruct &s) {<br>
> ...<br>
> }<br>
><br>
> Furthermore, suppose that I would like to annotate s.b's memory in the program state, without also annotating s.a and s.c. When I retrieve the region referenced by s, I observe that it is a SymbolicRegion, which is to be expected. I cannot, however, see any way to reason about any of its SubRegions individually, in this case s.a, s.b, and s.c.<br>
><br>
> I understand that SymbolicRegions are supposed to represent memory regions whose values the analyzer cannot properly model. But it still should be able to recognize that from foo's point of view, s has a well-defined structure with three FieldRegions, though their values must be symbolic.<br>
><br>
> Any help would be very much appreciated.<br>
><br>
> ~Scott Constable<br>
</div></div>> _______________________________________________<br>
> cfe-dev mailing list<br>
> <a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
> <a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=UVc407_CCx3FapxjS2xZ9jo4Q91upSGpJHRF8fPPYVY&m=McTLqDaevUEYvxyK7t8Q3qCLtLWFZirALoa9unrrrk0&s=21oO0iFZerhi2RxOUTvRUM_o9LWvt91q4Uz6S6YzmS8&e=" rel="noreferrer" target="_blank">https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.llvm.org_cgi-2Dbin_mailman_listinfo_cfe-2Ddev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=UVc407_CCx3FapxjS2xZ9jo4Q91upSGpJHRF8fPPYVY&m=McTLqDaevUEYvxyK7t8Q3qCLtLWFZirALoa9unrrrk0&s=21oO0iFZerhi2RxOUTvRUM_o9LWvt91q4Uz6S6YzmS8&e=</a><br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div><br></div>