From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14520 invoked by alias); 25 Nov 2001 16:33:20 -0000 Mailing-List: contact gdb-patches-help@sourceware.cygnus.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14224 invoked from network); 25 Nov 2001 16:32:03 -0000 Received: from unknown (HELO devserv.devel.redhat.com) (199.183.24.200) by sourceware.cygnus.com with SMTP; 25 Nov 2001 16:32:03 -0000 Received: (from jakub@localhost) by devserv.devel.redhat.com (8.11.0/8.11.0) id fAPGW2328293 for gdb-patches@sources.redhat.com; Sun, 25 Nov 2001 11:32:02 -0500 Date: Sat, 10 Nov 2001 16:27:00 -0000 From: Jakub Jelinek To: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fix sparc-*-linux register fetching/storing Message-ID: <20011125113201.C4087@devserv.devel.redhat.com> Reply-To: Jakub Jelinek References: <20011123154220.A562@sunsite.ms.mff.cuni.cz> <20011125020147.A32180@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20011125020147.A32180@nevyn.them.org>; from drow@mvista.com on Sun, Nov 25, 2001 at 02:01:47AM -0500 X-SW-Source: 2001-11/txt/msg00209.txt.bz2 On Sun, Nov 25, 2001 at 02:01:47AM -0500, Daniel Jacobowitz wrote: > On Fri, Nov 23, 2001 at 03:42:21PM +0100, Jakub Jelinek wrote: > > Hi! > > > > On sparc-*-linux, bfd automatically supports both 32bit and 64bit ABI and > > thus CORE_ADDR is 64bit type. Unfortunately, this means %l0-%i7 registers > > are read from incorrect place (and stored too), particularly from caller's > > instruction chain. This means even simple commands like next or bt don't > > work at all. > > Ok to commit? > > After this patch, Sparc still seems to be a little badly off > (particularly in calling inferior functions), but much better than > before. I'm a little confused about it though; I don't think it's > correct. I was fixing what I saw (and the next thing I got hit was a ld bug that cleared some .stab values in shared libs, so I had to recompile all shared libs). > > - target_read_memory (*(CORE_ADDR *) & registers[REGISTER_BYTE (SP_REGNUM)], > > - ®isters[REGISTER_BYTE (L0_REGNUM)], > > + CORE_ADDR sp = *(unsigned int *) & registers[REGISTER_BYTE (SP_REGNUM)]; > > + target_read_memory (sp, ®isters[REGISTER_BYTE (L0_REGNUM)], > > How was this going wrong exactly? We don't have any assurance that I > can think of that the stack will always be under the 32-bit mark in a > true 64-bit userland. The code in sparc-nat.c is not able to do 64bit userland. Solaris I believe uses completely different code, SunOS cannot go 64bit and for Linux it would have to use PT_GETREGS64 and the like. Actually, Dave Miller and myself used to have a patch for this which made gdb work at least a little bit with 64bit binaries, but it was not combo 32/64bit gdb which would require far more work (with most complicated stuff like solib.c for 32bit and 64bit in the same binary). > Is the entry in registers[] only four bytes long? If so, it seems that > using regcache_collect here is the way to go. For Sparc, which doesn't > sign-extend the way MIPS does, collecting four bytes out of the > register cache should be fine. I don't understand how regcache_collect would help here, since the assertion REGISTER_RAW_SIZE() == 4 would stay. That's just trading a dereference with a memcpy to an int variable. Jakub