From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9745 invoked by alias); 9 Aug 2002 20:59:40 -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 9738 invoked from network); 9 Aug 2002 20:59:38 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 9 Aug 2002 20:59:38 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g79KkKl06699 for ; Fri, 9 Aug 2002 16:46:20 -0400 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 g79KxYu08173; Fri, 9 Aug 2002 16:59:35 -0400 Received: from romulus.sfbay.redhat.com (remus.sfbay.redhat.com [172.16.27.252]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g79KxXe01523; Fri, 9 Aug 2002 13:59:33 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g79KxPV11150; Fri, 9 Aug 2002 13:59:26 -0700 Date: Fri, 09 Aug 2002 13:59:00 -0000 From: Kevin Buettner Message-Id: <1020809205925.ZM11149@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [RFA] Rewrite mips_get_saved_register()" (Aug 9, 12:12pm) References: <1020809003710.ZM26327@localhost.localdomain> <3D53EA0A.2030405@ges.redhat.com> To: Andrew Cagney , Kevin Buettner Subject: Re: [RFA] Rewrite mips_get_saved_register() Cc: gdb-patches@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00222.txt.bz2 On Aug 9, 12:12pm, Andrew Cagney wrote: > > This patch depends on the following (as of yet) unapproved patches: > > > > http://sources.redhat.com/ml/gdb-patches/2002-08/msg00189.html > > http://sources.redhat.com/ml/gdb-patches/2002-08/msg00195.html > > http://sources.redhat.com/ml/gdb-patches/2002-08/msg00196.html > > > > Okay to commit? > > > > * mips-tdep.c (mips_get_saved_register): Rewrite to use > > frame_register_unwind() instead of find_saved_register(). > > Sorry, not like this. Can you please, for the moment, just in-line the > call to find_saved_register(). > > (The two other bugs you fixed were definitly needed and thanks for > finding them. How the code got away with not setting the SP I don't know.) > > - if (raw_buffer != NULL) > - > { > - > LONGEST val; > - > if (regnum < 32) > - > /* Only MIPS_SAVED_REGSIZE bytes of GP registers are > - saved. */ > - > val = read_memory_integer (addr, MIPS_SAVED_REGSIZE); > - > else > - > val = read_memory_integer (addr, REGISTER_RAW_SIZE (regnum)); > - > store_address (raw_buffer, REGISTER_RAW_SIZE (regnum), val); > - > } > > In theory (and emphasis on the theory) things need to be changed so that: > > - 32 32 bit nameless pseudo-registers are added to the cooked register space > - the 32 64 bit gprs get given a 64 bit virtual type so that they have > identical raw and virtual sizes > - The debug info, for a 32 bit ABI, maps the gpr register numbers onto > the 32 bit pseudo register range > - The gdbarch pseudo register read/write function maps the 32 bit > pseudo-registers onto the 64 bit gprs. > - For init saved regs, dependant on the size of the register saved, > either the the address of the 64 bit GPR or the address of the 32 bit > pseudo-register is set > - a custom mips register unwind function maps the requested register (64 > bit gpr or 32 bit pseudo) onto: the 32 bit pseudo, the 64 bit gpr, or a > further recursive unwind call. If it has to do a 32/64 mapping then it > sets not-an-lval. > - you find you have to yank all sorts of register converible code > > But like I said, it is theory, the mips suffers from one hack (like the > above) piled on top of another (the register convertable stuff, the > register raw/virtual size being different, ...). I don't know if now is > the time to be experimenting with theories :-) Yes, fixing all of the above is quite a lot more work than I have time for at the moment. But, assuming that my rewrite is functionally equivalent to the original, what is the reason for preferring to inline find_saved_register() over using the new interface? I should think that using frame_register_unwind() would: - allow it to be better tested. E.g, I wouldn't have found the bugs that I did recently had I not gone through this exercise. - shorten the time needed to reexamine mips_get_saved_register() when it finally does come time to reimplement or eliminate it. Kevin