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

[Luis Machado]

On 09/19/2014 02:39 PM, Luis Machado wrote:
> Hi,
>
> On 09/19/2014 02:11 PM, Pedro Alves wrote:
>> 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?
>>
>
> That is a dangerous question! It could create infinite work. :-)
>
> In a quick response, I'd move that data out of the value struct and put
> it in the type struct, but that would require additional changes to
> prevent sharing the base types that have bit field data in them.
>
> For a longer answer, i think for everyday normal use GDB's current type
> mechanism works OK, but if you go beyond that and start doing alternate
> named address spaces, different kinds of pointers and strange type
> castings you start to reach the limits of the assumptions GDB makes (or
> has made in the past). There is definitely room for improvement in the
> type system.
>
> The difficulty to change this is because the type mechanism is a bit
> entangled with the symbol machinery and the DWARF reader, with potential
> for breakage.
>
> I haven't dealt much with C++ types, but from what I've dealt with, it
> seems we have some difficulties in there too. Again, it works, but could
> be better.
>
> Anyway, i think this has potential for a bigger and interesting discussion.
>
>>>
>>> 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 thought about doing that, but seems weird to have a function parameter
> just for the bit field information. I'm not sure if we're not missing
> other bits of information that may be useful for register/value
> conversion, that's why i went with passing the value structure. It holds
> everything anyway, not just the bit field data.
>
> Passing the bit size is OK with me though.
>
>>> 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?
>>
>
> I meant the functions that have to act on the type that is passed as a
> parameter rather than the value itself, like the following:
>
> gdbarch_register_to_value
> gdbarch_value_to_register
> gdbarch_value_from_register
>
> The dummy call hook already acts on the value structs of the parameters,
> so it doesn't sound totally wrong to want to pass the value struct in
> this case too.

ping! Any ideas on different approaches suitable for this problem or is 
the proposed fix ok (with either passing a value struct or a bit size)?

Thanks,
Luis