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
