From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27405 invoked by alias); 26 Sep 2014 15:45:54 -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 27394 invoked by uid 89); 26 Sep 2014 15:45:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS,UNSUBSCRIBE_BODY autolearn=no 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, 26 Sep 2014 15:45:53 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8QFjjhc014513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 26 Sep 2014 11:45:49 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8QFGhuf032248; Fri, 26 Sep 2014 11:16:44 -0400 Message-ID: <5425835B.609@redhat.com> Date: Fri, 26 Sep 2014 15:45: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> <541C63DF.8090206@redhat.com> <541C6A43.2000200@codesourcery.com> <54246DAE.6080208@codesourcery.com> In-Reply-To: <54246DAE.6080208@codesourcery.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2014-09/txt/msg00792.txt.bz2 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 (); } } Thanks, Pedro Alves