From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18245 invoked by alias); 19 Sep 2014 17:12:06 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 18141 invoked by uid 89); 19 Sep 2014 17:12:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 19 Sep 2014 17:12:04 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8JHC17R012865 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 19 Sep 2014 13:12:01 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8JHBxXQ012115; Fri, 19 Sep 2014 13:12:00 -0400 Message-ID: <541C63DF.8090206@redhat.com> Date: Fri, 19 Sep 2014 17:12:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: lgustavo@codesourcery.com, "'gdb-patches@sourceware.org'" Subject: Re: [PATCH] MIPS bit field failures in gdb.base/store.exp References: <5413534F.7000705@codesourcery.com> In-Reply-To: <5413534F.7000705@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00636.txt.bz2 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