Re: [PATCH] MIPS bit field failures in gdb.base/store.exp

[Pedro Alves <palves@redhat.com>]

Hi Luis,

On 09/12/2014 09:10 PM, Luis Machado wrote:

> Now, GDB knows how to do bit field assignment properly, but MIPS is one 
> of those architectures that uses a hook for the register-to-value 
> conversion. Although we can properly tell when the type being passed is 
> a structure or union, we cannot tell when it is a bit field, because the 
> bit field data lives in a value structure. Such data only lives in a 
> "type" structure when the parent structure is being referenced, thus you 
> can collect them from the flds_bnds members.
> 

> A bit field type structure looks pretty much the same as any other 
> primitive type like int or char, so we can't distinguish them. Forcing 
> more fields into the type structure wouldn't help much, because the type 
> structs are shared.

If we can't do that, then ...

> It feels to me GDB's type system is a bit dated and needs to be more 
> precise about what it is describing, but for now i just want to fix a 
> pending bug.

... this leaves me wondering about what you're thinking we'd
do differently if we had infinite time?

> 
> The most elegant solution i could find without having to touch a number 
> of other type-related data structures is making the 
> gdbarch_convert_register_p predicate accept a value structure instead of 
> a type structure. That way we can properly tell when a bit field is 
> being manipulated in registers.
> 
> There is still a little problem though. We don't always have a 
> meaningful value struct to pass to this predicate, like both ocurrences 
> of it in findvar.c. In those cases i went for a dummy value.
> 
> In the end, it is functional but a bit ugly. Unless folks have a better 
> suggestion, is this ok?

Well, why not pass down value_bitsize() (an integer) instead of
the whole value?

> I did tests with x86, mips32 be/le and mips64 be/le. No regressions found.
> 
> The lack of bit field data in the type struct also affects other 
> functions that rely on type descriptions, though there may not be 
> explicit failures due to those yet.

That's a bit vague.  :-)  Got pointers?

Thanks,
Pedro Alves