From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5771 invoked by alias); 25 Nov 2001 07:01:44 -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 5736 invoked from network); 25 Nov 2001 07:01:34 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sourceware.cygnus.com with SMTP; 25 Nov 2001 07:01:34 -0000 Received: from drow by nevyn.them.org with local (Exim 3.32 #1 (Debian)) id 167tIR-0008Pj-00; Sun, 25 Nov 2001 02:01:47 -0500 Date: Sat, 10 Nov 2001 13:03:00 -0000 From: Daniel Jacobowitz To: Jakub Jelinek Cc: gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fix sparc-*-linux register fetching/storing Message-ID: <20011125020147.A32180@nevyn.them.org> Mail-Followup-To: Jakub Jelinek , gdb-patches@sources.redhat.com References: <20011123154220.A562@sunsite.ms.mff.cuni.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20011123154220.A562@sunsite.ms.mff.cuni.cz> User-Agent: Mutt/1.3.23i X-SW-Source: 2001-11/txt/msg00205.txt.bz2 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. > - 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. 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. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer