From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26237 invoked by alias); 13 Nov 2002 19:55:08 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 26198 invoked from network); 13 Nov 2002 19:55:06 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 13 Nov 2002 19:55:06 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id gADJVqw05235 for ; Wed, 13 Nov 2002 14:31:52 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id gADJt4x26845; Wed, 13 Nov 2002 14:55:04 -0500 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id gADJt4H12249; Wed, 13 Nov 2002 11:55:04 -0800 Message-ID: <3DD2AE18.C1D0E978@redhat.com> Date: Wed, 13 Nov 2002 11:55:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Richard.Earnshaw@arm.com CC: gdb-patches@sources.redhat.com Subject: Re: [RFA] arm_store_return_value, big-endian (take 2) References: <200211121014.gACAEtF31639@pc960.cambridge.arm.com> Content-Type: multipart/mixed; boundary="------------F0A8E05CB217AAA75A473DA3" X-SW-Source: 2002-11/txt/msg00392.txt.bz2 This is a multi-part message in MIME format. --------------F0A8E05CB217AAA75A473DA3 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-length: 1756 Richard Earnshaw wrote: > > > Richard Earnshaw wrote: > > > > > > > Richard Earnshaw wrote: > > > > > > > > > > > Richard Earnshaw wrote: > > > > > > > > > > > > > > Leaving asside the issue of the correctness of write_register_bytes (note > > > > > > > to self, must finish of my register patches), I don't think this is > > > > > > > correct -- in fact, I think it's also wrong for little-endian as well. > > > > > > > > > > > > > > What should happen is that the smaller-than-word value should be > > > > > > > zero/sign-extended to 32 bits and then the whole thing stored in A1_REGNUM. > > > > > > > > > > > > Ah, thanks. OK, how about this? > > > > > > > > > > > > 2002-11-06 Michael Snyder > > > > > > > > > > > > * arm-tdep.c (arm_store_return_value): Handle offset of > > > > > > small types on big-endian machines. > > > > > > > > > > And for little-endian? > > > > > > > > It already works for little-endian. I've tested this with > > > > arm-sim, arm-sim/-mbig-endian, and arm-sim/-mthumb. > > > > > > But it's not zero/sign extending properly for little-endian, so garbage is > > > remaining in the top part of A1 > > > > Ah; well, I didn't make it any worse! ;-) > > Can I leave that detail for someone else, and just > > submit this minor improvement? > > Given that to fix this for little-endian as well means that you just have > to *remove* the endianness test from your patch, why is that so hard???!!!! Oh, I see. Yes, it's no longer necessary. But if it's not so hard, and you already see what's necessary, why not just do it instead of ragging on me to do it? ;-) This what you have in mind? Please just take it from here, I really didn't intend to spend this much time and energy on it. --------------F0A8E05CB217AAA75A473DA3 Content-Type: text/plain; charset=us-ascii; name="arm6.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="arm6.patch" Content-length: 722 Index: arm-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/arm-tdep.c,v retrieving revision 1.74 diff -p -r1.74 arm-tdep.c *** arm-tdep.c 1 Nov 2002 21:21:49 -0000 1.74 --- arm-tdep.c 13 Nov 2002 19:48:21 -0000 *************** arm_store_return_value (struct type *typ *** 2417,2424 **** break; } } ! else ! write_register_bytes (ARM_A1_REGNUM, valbuf, TYPE_LENGTH (type)); } /* Store the address of the place in which to copy the structure the --- 2417,2424 ---- break; } } ! else ! write_register (ARM_A1_REGNUM, unpack_long (type, valbuf); } /* Store the address of the place in which to copy the structure the --------------F0A8E05CB217AAA75A473DA3--