[cfe-dev] [analyzer] Binding address-of globals

[Rafael·Stahl via cfe-dev]

Alright thanks for the info. As I see it number 2 should already be 
solved, but number 1 is still not clear to me.

The issue is that there is no direct binding available, as is with the 
non-global case.

- Non-global: Will return direct binding from getBindingForField. The 
initialization earlier in main caused this direct binding.

- Global: Does not find direct binding in getBindingForField and cannot 
resolve FieldInit to a constant.

Now I could add some code to the case where getConstantVal fails to look 
at the FieldInit Expr and return a new FieldRegion in a 
loc::MemRegionVal if I find UnaryOp(&) -> DeclRefExpr(FieldDecl). The 
issue is that this is very tailored to the example and does not work in 
general. I feel like the SVal for the FieldInit Expr should be available 
somewhere but I cannot figure out where.

There is ProgramState::getSVal(const Stmt*, const LocationContext*) but 
not sure if this is applicable here - also because the RegionStore 
doesn't seem to have any ProgramState or LocationContext.

Rafael


On 12.06.2018 01:59, Artem Dergachev wrote:
> Hmm. It sounds as if we need to fix both things here, and both of them 
> are something that you already know how to solve:
>
> 1. Be able to constant-fold "gs.sub" to "&gsubs",
> 2. Be able to constant-fold "(&gsubs)->p" to "0x80008000".
>
> I guess the confusion arises because steps 1 and 2 are separated in 
> time; they are in fact two independent loads. They interact through 
> the Environment: we compute the sub-expression, put its value into the 
> Environment, then later when we need to perform the second load we can 
> retrieve the value from the Environment. Once we perform the first 
> load correctly, it becomes irrelevant that such load ever happened; 
> ExprEngine, like checkers, is stateless. The problem becomes as easy 
> as loading "gsubs.p" because the analyzer knows, in path-sensitive 
> manner, that the sub-expression "gs.sub" has evaluated to "&gsubs"; 
> that'd be already encoded in the MemRegion structure.
>
> So i think we don't need to retroactively create anything. Instead, we 
> simply need to perform every step precisely. Which is anyway a good 
> thing because there's always code that never gets to the second step.
>
> Sorry if the answer is not spot-on; i'm not sure i fully understood 
> the question.
>
> On 6/7/18 1:52 AM, Rafael·Stahl via cfe-dev wrote:
>> Hi,
>>
>> continuing my effort to make the analyzer understand more constants, 
>> I did take a look at the following case:
>>
>>
>> struct SubS {
>>     int *p;
>> };
>>
>> struct S {
>>     struct SubS *sub;
>> };
>>
>> struct SubS const gsubs = {
>>     .p = 0x80008000
>> };
>> struct S const gs = {
>>     .sub = &gsubs
>> };
>>
>> int main() {
>>     struct SubS subs = {
>>         .p = 0x80008000
>>     };
>>     struct S s = {
>>         .sub = &subs
>>     };
>>
>>     *s.sub->p;
>>     *gs.sub->p;
>> }
>>
>> Here, the analyzer recognizes the dereference via s, but not gs. This 
>> seems to be the case because region information will be stored for 
>> subs, but not for gsubs.
>>
>> I'm not sure how to solve this issue. Could we retroactively create 
>> the region information whenever we encounter constants like this? Or 
>> rather add something to the getBinding functions that manually 
>> resolves this case? For the latter it seems like the analyzer should 
>> already understand what is happening without many additions, but it's 
>> unclear to me how it connects.
>>
>> Best regards
>> Rafael
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180612/c14d156a/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5449 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180612/c14d156a/attachment.bin>