From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10999 invoked by alias); 10 Feb 2016 17:36:22 -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 10978 invoked by uid 89); 10 Feb 2016 17:36:22 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1803 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; Wed, 10 Feb 2016 17:36:21 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id 282A37AE8C; Wed, 10 Feb 2016 17:36:20 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u1AHaJI9024918; Wed, 10 Feb 2016 12:36:19 -0500 Message-ID: <56BB7512.2030507@redhat.com> Date: Wed, 10 Feb 2016 17:36:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Yao Qi CC: gdb-patches@sourceware.org Subject: Re: [PATCH] Clear *VAL in regcache_raw_read_unsigned References: <1455029644-6197-1-git-send-email-yao.qi@linaro.org> <86egckqztq.fsf@gmail.com> <56BB6ADB.6070909@redhat.com> <86a8n8qxyp.fsf@gmail.com> In-Reply-To: <86a8n8qxyp.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00310.txt.bz2 On 02/10/2016 05:25 PM, Yao Qi wrote: > Pedro Alves writes: > > Hi Pedro, > >> Isn't this broken on big endian? AFAICS, we're reading 32-bits into >> the higher 32-bits of a 64-bit variable. > > What do you mean by "this"? IIUC, "this" means > regcache_raw_read_unsigned, rather than my patch. My patch just clears > *VAL before passing it to collect_register, so it shouldn't break anything > (I hope) on big endian. The issue you noticed exposed that regcache_raw_read_unsigned function is broken for memcpy'ing a 32-bit value into a 64-bit variable, and I think your patch papered over the problem for little endian, only. enum register_status regcache_raw_read_unsigned (struct regcache *regcache, int regnum, ULONGEST *val) { int size; gdb_assert (regcache != NULL); gdb_assert (regnum >= 0 && regnum < regcache->tdesc->num_registers); size = register_size (regcache->tdesc, regnum); if (size > (int) sizeof (ULONGEST)) error (_("That operation is not available on integers of more than" "%d bytes."), (int) sizeof (ULONGEST)); collect_register (regcache, regnum, val); return REG_VALID; } VAL is 64-bit. collect_register () writes directly into VAL, but it only writes 32-bits. On little endian, that will leave the upper halve of VAL as garbage. So your patch clears that. But on big endian, that collect_register() call writes into the upper halve of VAL, and the result is that VAL now has the wrong value. E.g., if the 32-bit register's value is supposed to be 0x11223344, after the collect register call, *VAL ends up with 0x1122334400000000, which happens to work for little endian, but not for big endian. You should be able to trigger this on an ARM system with big endian code. Thanks, Pedro Alves