This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] MIPS bit field failures in gdb.base/store.exp
- From: Pedro Alves <palves at redhat dot com>
- To: lgustavo at codesourcery dot com, "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Date: Fri, 19 Sep 2014 18:11:59 +0100
- Subject: Re: [PATCH] MIPS bit field failures in gdb.base/store.exp
- Authentication-results: sourceware.org; auth=none
- References: <5413534F dot 7000705 at codesourcery dot 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