From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27662 invoked by alias); 19 Sep 2014 16:45:30 -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 27647 invoked by uid 89); 19 Sep 2014 16:45:28 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 Sep 2014 16:45:26 +0000 Received: from svr-orw-fem-05.mgc.mentorg.com ([147.34.97.43]) by relay1.mentorg.com with esmtp id 1XV1JD-0004pl-AK from Luis_Gustavo@mentor.com for gdb-patches@sourceware.org; Fri, 19 Sep 2014 09:45:23 -0700 Received: from [172.30.12.3] (147.34.91.1) by svr-orw-fem-05.mgc.mentorg.com (147.34.97.43) with Microsoft SMTP Server id 14.3.181.6; Fri, 19 Sep 2014 09:45:23 -0700 Message-ID: <541C5D9D.9030809@codesourcery.com> Date: Fri, 19 Sep 2014 16:45:00 -0000 From: Luis Machado Reply-To: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: "'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="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00634.txt.bz2 On 09/12/2014 05:10 PM, Luis Machado wrote: > 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 Ping! Any thoughts on the proposed solution?