[cfe-dev] [analyzer] Calling SymbolReaper::markInUse on BinarySymExprs are ignored

Artem Dergachev via cfe-dev cfe-dev at lists.llvm.org
Thu Aug 20 15:45:37 PDT 2020



On 8/20/20 9:41 AM, Gábor Horváth wrote:
>
> On Wed, 19 Aug 2020 at 23:18, Artem Dergachev <noqnoqneo at gmail.com 
> <mailto:noqnoqneo at gmail.com>> wrote:
>
>     Gabor, we've talked about this two days ago >_>
>
> This email is much easier to follow than a verbal discussion :D Now I 
> have a much better understanding of what you meant.
>
>
>     I believe we should remove SymbolConjured's identity elements from
>     SymbolMetadata and instead make it work more like
>     SymbolRegionValue works in RegionStore. Namely:
>
>
> If SymbolMetadata works like SymbolRegionValue, do we actually need 
> both? I mean I do understand that we use them for different purposes, 
> but we could also have a type alias or something like that if that 
> actually helps understanding how the analyzer works.

Yes, i believe they can be technically backed by the same re-used 
implementation.

Btw i just unforgot about the deep connection between SymbolRegionValue 
and SymbolDerived. We'll also probably need to introduce derived 
metadata. Say, if a smart pointer is part of a bigger object and that 
bigger object is invalidated, it doesn't mean that we immediately 
conjure a bunch of symbols for all raw values in all smart pointers that 
we aren't tracking that are sub-regions of that object; instead, we 
could simply start producing derived metadata instead of normal metadata 
when asked.

>
>     2. Get rid of the metadata-in-use set. From now on SymbolMetadata,
>     like SymbolRegionValue, is live whenever its region is live.
>
>
> Will this work for code examples where the actual string is already 
> dead but we still want to compute with its length?

When i say "is live whenever its region is live", i mean that the 
opposite is not necessarily true. If the symbol is stored anywhere in 
memory then it's definitely live.

Like, generally, all objects can be "internally live" (example: 
"SymbolRegionValue<R> is internally live if R is live [externally or 
internally]") or "externally live" (which can be only determined by 
exploring the current exploded node in its entirety and implemented via 
populating live and dead sets, example: "if symbol $x is written into 
region R and R is live [externally or internally] then $x is externally 
live").

I was talking about internal liveness rules; external liveness rules are 
untouched.

Such mental distinction is pretty important because only finite amount 
of symbols can be externally live (as the amount of info in the state is 
finite, and so is the live set); the amount of internally live symbols 
is potentially infinite.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200820/c49c0d25/attachment.html>


More information about the cfe-dev mailing list