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