On 17/01/2024 23:52, David Malcolm wrote:
> On Tue, 2024-01-16 at 15:44 +0100, Pierrick Philippe wrote:
>> Hi David, hi all,
> Hi Pierrick.
First, thanks for you answer.
[stripping]
> I confess that I've been quite sloppy in places with types in the
> analyzer, keeping track of them when it's easy, but letting them be
> NULL in places where getting a type was hard, or apparently not
> possible.
>
> Sorry about this.
>
> I think my implementation is a bit muddled about what an svalue
> actually is.
>
> Informally, I think of an svalue as a partial function from bit offsets
> to values of the bits.  For example:
> * region_svalue: e.g. bit offsets 0-63 are the pointer to REG;
> undefined elsewhere
> * constant_svalue: e.g. given (int)42, bit offsets 0-31 are the
> constant 42, encoded in the target's usual way; undefined elsewhere
> * unknown_svalue: undefined everywhere
> ...etc, and the above definition doesn't need svalues to have a type.
>
> The above is rather vague: how should this work for unaryop_svalue and
> binop_svalue; these need to have types, so that we can think of them as
> e.g. 
> * "bits 0-31 are the result of a signed 32-bit int addition of the
> values of bits 0-32 from X and Y when considered as signed 32-bit int".
> * "bits 0-31 are the result of zero-extending bits 0-7 of X and
> treating the result as uint32_t".

I do understand, but here, the thing is that the analyzer built a
region_svalue without any type. And thought it was a bit weird.

But I do get your point here.

> In the meantime, you can't rely on an svalue having a non-NULL type,
> and hence it's often not possible to get a representative tree from an
> svalue, since tree expressions must have non-NULL types.

But then, shouldn't the analyzer have a defensive approach in
get_representative_tree and return a NULL_TREE in such cases? Because
the segfault is happening behind the scene. Maybe it shouldn't, I have
no idea what would be the best approach here.

>> But from this, two questions raised in my mind:
>>
>> 1. Is it coherent for the ana::region_model_manager::get_ptr_svalue
>> to
>> return a sval with a null type?
> It depends what you mean by "coherent"; given the sloppy approach
> above, the answer is "yes".
(nod)
>> 2. Can a tree view as a tree_type_common member have an uninitialized
>> pointer_to member?
> It shouldn't be uninitialized.  Perhaps the tree node isn't the right
> kind?  You should use the TYPE_POINTER_TO macro to access the field,
> which will use TYPE_CHECK to check that the node is a type in a debug
> build of the compiler.
Well, I'm pretty sure I didn't build it myself and only used macros
and API functions to get that type. And this is what is confusing me.

[stripping]

> Sounds like a bug; please try to construct a minimal example.
Sure, I'll try to build a minimal example.
Will have to use a plugin to do so though, hope that won't be a problem.

Thanks,
Pierrick

> Thanks
> Dave
>
>> Thank you for reading me,
>>
>> Pierrick

Reply via email to