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

[Luis Machado <lgustavo@codesourcery.com>]

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.

Luis