From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31313 invoked by alias); 14 May 2002 20:06:22 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 31304 invoked from network); 14 May 2002 20:06:20 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 14 May 2002 20:06:20 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id D02E03E60; Tue, 14 May 2002 16:06:28 -0400 (EDT) Message-ID: <3CE16E44.8070807@cygnus.com> Date: Tue, 14 May 2002 13:06:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc1) Gecko/20020429 X-Accept-Language: en-us, en MIME-Version: 1.0 To: thorpej@wasabisystems.com Cc: Richard.Earnshaw@arm.com, gdb@sources.redhat.com Subject: Re: Saving/restoring the entire register set References: <200205141517.QAA18465@cam-mail2.cambridge.arm.com> <20020514082856.O3435@dr-evil.shagadelic.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00155.txt.bz2 Interesting timeing, > The current implementation of generic_{push,pop}_dummy_frame use > > {read,write}_register_bytes (0, addr, REGISTER_BYTES) > > to save/restore the entire regset. Interesting timing, see: http://sources.redhat.com/ml/gdb/2002-05/msg00116.html > This is causing a problem for me with the new pseudo/raw register > separation that I'm trying to create because write_register_bytes calls > write_register_gen which calls arm_register_write and then aborts because > we are trying to directly update a raw register rather than a pseudo. Hmm, {read,write} register bytes can call the legacy {read,write} register gen. Those functions provide the behavour the {read,write} bytes functions rely on. I guess I didn't notice this when adding regcache_read(). For the record (per numerious change requests) {read,write} register bytes need to be snuffed out. > While the dummy frame code does seem to be doing something sensible, doing > it this way is somewhat of a pain, because I really want to fault out > attempts to directly poke into the raw registers (I've already tracked down > two or three bugs this way). > > For this special case of saving/restoring the entire register bank, I wonder if a more suitable interface might be to have calls such as > > struct regcache *regcache_alloc (); /* Allocate a new regcache structure */ > regcache_save (regcache); /* Copy current registers into it */ > regcache_restore (regcache); /* Restore registers from it */ > regcache_free (regcache); /* Release it */ > > which would directly perform the precise operations that are required. > > These routines could then directly use the legacy_{read,write}_register_gen > interface to fill/restore a copy of the structure. [Since someone will likely now look at that post] -- regbuf.[hc] adds just a register buffer. It should be a raw register only buffer except .... (sigh). The objective is purely to replace registers[] with an object. If you look through the patch, you'll notice that I also modify functions such as extract_struct_value_adress and value_being_returned to take a ``struct regbuf'' instead of the raw registers array. That part is strictly a sideways transformation - I'm not trying to fix anything. -- I think, eventually, there will be a ``struct state'' object that makes available either the live (call through to the target register/memory code) or saved (just consult the local cache) state of the target. The saved state could include both saved registers and memory. This is why a ``struct regcache'' wouldn't do the trick. I've seen one target that needs to restore memory to correctly recover from a call dummy (fortunatly no one has tried to integrate this into current gdb). Functions such as extract_struct_value_address would take this object instead of registers[]/regbuf. That code could then call register {read,write} (which also takes a ``struct state'') to read/write values. -- At present GDB saves and restores all the raw registers. This is overkill. After an inferior function call, you probably don't want to restore all the registers (in fact you probably don't want to save them - forcing them to be fetched from the target). Hence, architecture methods like: raw_register_save_p() raw_register_restore_p() will be needed. -- thoughts, Andrew