Read offsets separately in eval_rv_base for pointer dereference

[jerhard]

This PR changes the treatment of pointer dereference eval_rv_base and the Structs.get method, to avoid producing top in the cases described in #716.

The change affects the case that eval_rv_base evaluates a pointer that is dereferenced and some offset is taken from the resulting value. Previously, all objects that the pointer could point to without the offset. Then, these memory objects were joined, and the offset was taken from the result. This led to additional imprecision in case of the join of e.g. structs of different type.

Now, eval_rv_base will look at all the possible target addresses, and read for each of them the value at the offset. Then, the values at the offsets are joined, to produce the result.
The struct domain is changed such that get yields a top_value of the corresponding type, rather than 'Top. This way, if a field of pointer type is requested, but the abstract value does not contain the field, a top pointer ({?, NULL}) is constructed instead of 'Top. By avoiding to produce the 'Top in this case, addresses are read from structs of the appropriate type are kept in the result of the join.

Closes #716.

[jerhard]

When the list of malloc-wrappers is provided to Goblint, this also fixes the issue of warnings for no suitable function existing for dynamic function calls dereferencing pointers with some field offset, e.g.:

[Warning][Unsound] Unknown call to function *(inst->handler). (nameserv_async.c:94:4-94:66)
[Warning][Unsound] No suitable function to be called at call site. Continuing with state before call. (nameserv_async.c:94:4-94:66)

There remain four cases of "No suitable function to be called at call site. Continuing with state before call", however, these are cases, where the function pointer is only ever set to Null. So this is not an issue caused by the analysis.

[sim642]

Now, eval_rv_base will look at all the possible target addresses, and read for each of them the value at the offset. Then, the values at the offsets are joined, to produce the result.

This replaces one eval_offset with as many as there are elements in the address set, which could have a performance impact.
I suppose the Munich benchmarking server is currently busy with interactive, so I'll do the benchmarks on the Tartu server.

[sim642]

This replaces one eval_offset with as many as there are elements in the address set, which could have a performance impact.
I suppose the Munich benchmarking server is currently busy with interactive, so I'll do the benchmarks on the Tartu server.

A bit surprisingly there's no effect:

(Full table)

I guess eval_offset is cheap enough.

[jerhard]

Thanks for benchmarking this! Good to know that it does in general not have a negative impact on performance.