From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23468 invoked by alias); 29 Sep 2014 12:36:24 -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 23456 invoked by uid 89); 29 Sep 2014 12:36:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,UNSUBSCRIBE_BODY autolearn=no 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; Mon, 29 Sep 2014 12:36:21 +0000 Received: from svr-orw-fem-04.mgc.mentorg.com ([147.34.97.41]) by relay1.mentorg.com with esmtp id 1XYaBe-0005X7-5i from Luis_Gustavo@mentor.com ; Mon, 29 Sep 2014 05:36:18 -0700 Received: from [172.30.12.34] (147.34.91.1) by svr-orw-fem-04.mgc.mentorg.com (147.34.97.41) with Microsoft SMTP Server id 14.3.181.6; Mon, 29 Sep 2014 05:36:18 -0700 Message-ID: <5429523F.3000706@codesourcery.com> Date: Mon, 29 Sep 2014 12:36: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: Pedro Alves , "'gdb-patches@sourceware.org'" Subject: Re: [PATCH] MIPS bit field failures in gdb.base/store.exp References: <5413534F.7000705@codesourcery.com> <541C63DF.8090206@redhat.com> <541C6A43.2000200@codesourcery.com> <54246DAE.6080208@codesourcery.com> <5425835B.609@redhat.com> In-Reply-To: <5425835B.609@redhat.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00830.txt.bz2 Hi, On 09/26/2014 12:16 PM, Pedro Alves wrote: > On 09/25/2014 08:31 PM, Luis Machado wrote: > >> ping! Any ideas on different approaches suitable for this problem or is >> the proposed fix ok (with either passing a value struct or a bit size)? > > Sorry, it's not easy to have a quick opinion without thinking this > through... > > So, in value_assign, the case in question, we see: > > gdbarch = get_frame_arch (frame); > if (gdbarch_convert_register_p (gdbarch, VALUE_REGNUM (toval), type)) > { > /* If TOVAL is a special machine register requiring > conversion of program values to a special raw > format. */ > gdbarch_value_to_register (gdbarch, frame, > VALUE_REGNUM (toval), type, > value_contents (fromval)); > } > > Notice how gdbarch_value_to_register takes the fromval's contents > as a buffer, only, and isn't passed down anything that would make it > possible to find out whether it's writing to a bitfield, so that > the implementation could do a read-modify-write itself and > write to the proper bitfield offset. > > So, it seems to me that until we find an arch that needs to handle > bitfields especially (I'm having trouble imagining why that > would be necessary), we should just change value_assign's > lval_register handling from: > > if (gdbarch_convert_register_p (gdbarch, VALUE_REGNUM (toval), type)) > { > gdbarch_value_to_register (); > } > else > { > if (value_bitsize (toval)) > { > // read-modify-write > } > else > { > put_frame_register_bytes (); > } > } > > to: > > if (value_bitsize (toval)) > { > // read-modify-write > } > else > { > if (gdbarch_convert_register_p (gdbarch, VALUE_REGNUM (toval), type)) > { > gdbarch_value_to_register (); > } > else > { > put_frame_register_bytes (); > } > } Though a bit less generic, that also seems to be a reasonable solution for now, and it fixes the failures i saw for MIPS. Out of the top of my head i also don't recall a target that handles bit fields in a special way. Should i go with this patch for the next submission or do you want to author it? Thanks, Luis