Hi,

I've been chasing this one for a while, trying to come up with the best 
solution while not having to do many changes to GDB's type system.

On MIPS64 little endian, attempting an assignment to a bit field that 
lives in a register yields the wrong result. It just corrupts the data 
in the register depending on the specific position of the bit field 
inside the structure.

FAIL: gdb.base/store.exp: f_1.j
FAIL: gdb.base/store.exp: f_1.k
FAIL: gdb.base/store.exp: F_1.i
FAIL: gdb.base/store.exp: F_1.j
FAIL: gdb.base/store.exp: F_1.k
FAIL: gdb.base/store.exp: f_2.j
FAIL: gdb.base/store.exp: f_2.k
FAIL: gdb.base/store.exp: F_2.i
FAIL: gdb.base/store.exp: F_2.j
FAIL: gdb.base/store.exp: F_2.k
FAIL: gdb.base/store.exp: f_3.j
FAIL: gdb.base/store.exp: f_3.k
FAIL: gdb.base/store.exp: F_3.i
FAIL: gdb.base/store.exp: F_3.j
FAIL: gdb.base/store.exp: F_3.k
FAIL: gdb.base/store.exp: f_4.j
FAIL: gdb.base/store.exp: f_4.k
FAIL: gdb.base/store.exp: F_4.i
FAIL: gdb.base/store.exp: F_4.j
FAIL: gdb.base/store.exp: F_4.k

                 === gdb Summary ===

# of expected passes            220
# of unexpected failures        20

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.

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.

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?

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.

Luis