From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4412 invoked by alias); 15 May 2002 10:09:10 -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 4403 invoked from network); 15 May 2002 10:09:08 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 15 May 2002 10:09:08 -0000 Received: by fw-cam.cambridge.arm.com; id LAA00128; Wed, 15 May 2002 11:09:06 +0100 (BST) Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma029301; Wed, 15 May 02 11:08:17 +0100 Received: from cam-mail2.cambridge.arm.com (cam-mail2.cambridge.arm.com [172.16.1.91]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id LAA17443; Wed, 15 May 2002 11:08:16 +0100 (BST) Received: from sun18.cambridge.arm.com (sun18.cambridge.arm.com [172.16.2.18]) by cam-mail2.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id LAA27449; Wed, 15 May 2002 11:08:15 +0100 (BST) Message-Id: <200205151008.LAA27449@cam-mail2.cambridge.arm.com> To: Andrew Cagney cc: thorpej@wasabisystems.com, Richard.Earnshaw@arm.com, gdb@sources.redhat.com Reply-To: Richard.Earnshaw@arm.com Organization: ARM Ltd. X-Telephone: +44 1223 400569 (direct+voicemail), +44 1223 400400 (switchbd) X-Fax: +44 1223 400410 X-Address: ARM Ltd., 110 Fulbourn Road, Cherry Hinton, Cambridge CB1 9NJ. X-Url: http://www.arm.com/ Subject: Re: Saving/restoring the entire register set In-reply-to: Your message of "Tue, 14 May 2002 16:06:28 EDT." <3CE16E44.8070807@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 15 May 2002 03:09:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-05/txt/msg00158.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 Hmm, the patch in that file is missing the contents of regbuf.[ch], so I can't try it, even if I wanted :-( > > > 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(). Missing out the intervening layers would probably solve the problem in this case. > > For the record (per numerious change requests) {read,write} register > bytes need to be snuffed out. Yes please... > 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. > How about creating a "regbuf" branch where we can play with these ideas a little more without the risk of destabilizing everything? That way we don't keep having to wait a week for each change to go in. R.