From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Daniel Jacobowitz Cc: Jakub Jelinek , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fix sparc-*-linux register fetching/storing Date: Mon, 26 Nov 2001 13:19:00 -0000 Message-id: <3C02B1D6.2030407@cygnus.com> References: <20011123154220.A562@sunsite.ms.mff.cuni.cz> <20011125020147.A32180@nevyn.them.org> <20011125113201.C4087@devserv.devel.redhat.com> <20011125115446.A15038@nevyn.them.org> <3C02795A.9000104@cygnus.com> <20011126150435.A6212@nevyn.them.org> <3C02A761.4030003@cygnus.com> <20011126154347.A8899@nevyn.them.org> X-SW-Source: 2001-11/msg00458.html > Well, remember that we can't cast things to (CORE_ADDR *) reliably. > With --enable-64-bit-bfd, that has a tendency to turn into a 'long long *'. > What was happening was reading $sp out of the regcache, and then > passing it to target_read_memory. If this were MIPS, I think we'd have > to sign extend there, for "correctness". We'd eventually truncate it > back down with a cast in infptrace.c, though. > > I just don't like duplicating that above code sequence everywhere we > get a pointer out of a register into a CORE_ADDR. It seems like a very > frequent operation, in nat or in tdep. [Carefully read code ... Hmm, why is it reading registers from memory (stack) ..... Hmm, why were all the registers written direct to the stack ...? Hmm, nothing does something that stupid except something with register windows .... Er, Oh dear....] Sorry, yes that code, as it stands, looks like it does need to do an extract_XXXX_address() call on the register. As it stands? gdbarch_register_read/write and the fetch registers for frame function should be mapping those registers onto memory addresses instead of passing the problem down to the target fetch register code. That way, those stored-in-memory registers are fetched via the memory and not the data cache. That, however, is currently just theory :-) Andrew From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15874 invoked by alias); 26 Nov 2001 21:19: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 15850 invoked from network); 26 Nov 2001 21:19:19 -0000 Received: from unknown (HELO localhost.cygnus.com) (24.147.211.196) by hostedprojects.ges.redhat.com with SMTP; 26 Nov 2001 21:19:19 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.cygnus.com (Postfix) with ESMTP id A075F3DBA; Mon, 26 Nov 2001 16:19:18 -0500 (EST) Message-ID: <3C02B1D6.2030407@cygnus.com> Date: Tue, 13 Nov 2001 08:28:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.3) Gecko/20011020 X-Accept-Language: en-us MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Jakub Jelinek , gdb-patches@sources.redhat.com Subject: Re: [PATCH] Fix sparc-*-linux register fetching/storing References: <20011123154220.A562@sunsite.ms.mff.cuni.cz> <20011125020147.A32180@nevyn.them.org> <20011125113201.C4087@devserv.devel.redhat.com> <20011125115446.A15038@nevyn.them.org> <3C02795A.9000104@cygnus.com> <20011126150435.A6212@nevyn.them.org> <3C02A761.4030003@cygnus.com> <20011126154347.A8899@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2001-11/txt/msg00243.txt.bz2 Message-ID: <20011113082800.oplUOinYW0N8ZAqJnBtoP6nZT02-M1PjZtEq6JDzY0Y@z> > Well, remember that we can't cast things to (CORE_ADDR *) reliably. > With --enable-64-bit-bfd, that has a tendency to turn into a 'long long *'. > What was happening was reading $sp out of the regcache, and then > passing it to target_read_memory. If this were MIPS, I think we'd have > to sign extend there, for "correctness". We'd eventually truncate it > back down with a cast in infptrace.c, though. > > I just don't like duplicating that above code sequence everywhere we > get a pointer out of a register into a CORE_ADDR. It seems like a very > frequent operation, in nat or in tdep. [Carefully read code ... Hmm, why is it reading registers from memory (stack) ..... Hmm, why were all the registers written direct to the stack ...? Hmm, nothing does something that stupid except something with register windows .... Er, Oh dear....] Sorry, yes that code, as it stands, looks like it does need to do an extract_XXXX_address() call on the register. As it stands? gdbarch_register_read/write and the fetch registers for frame function should be mapping those registers onto memory addresses instead of passing the problem down to the target fetch register code. That way, those stored-in-memory registers are fetched via the memory and not the data cache. That, however, is currently just theory :-) Andrew