From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19427 invoked by alias); 20 Feb 2002 16:45:38 -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 19341 invoked from network); 20 Feb 2002 16:45:36 -0000 Received: from unknown (HELO fw-cam.cambridge.arm.com) (193.131.176.3) by sources.redhat.com with SMTP; 20 Feb 2002 16:45:36 -0000 Received: by fw-cam.cambridge.arm.com; id QAA13920; Wed, 20 Feb 2002 16:45:34 GMT Received: from unknown(172.16.1.2) by fw-cam.cambridge.arm.com via smap (V5.5) id xma013213; Wed, 20 Feb 02 16:44:53 GMT Received: from cam-mail2.cambridge.arm.com (localhost [127.0.0.1]) by cam-admin0.cambridge.arm.com (8.9.3/8.9.3) with ESMTP id QAA08450; Wed, 20 Feb 2002 16:44:53 GMT 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 QAA09255; Wed, 20 Feb 2002 16:44:52 GMT Message-Id: <200202201644.QAA09255@cam-mail2.cambridge.arm.com> X-Mailer: exmh version 2.0.2 2/24/98 To: Andrew Cagney cc: 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: The regcache abstraction (Was Re: PATCH ARM initial support for different floating-point models) In-reply-to: Your message of "Tue, 19 Feb 2002 18:12:13 EST." <3C72DBCD.3000504@cygnus.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 Feb 2002 08:45:00 -0000 From: Richard Earnshaw X-SW-Source: 2002-02/txt/msg00254.txt.bz2 > Hmm, I'm afraid you may have just stepped into the > write_register_bytes() bear trap :-( Have a look at the comments in > regcache.c for the history. > Well if I was confused before, I'm totally flummoxed now. The more I try to wade through the different legacy interfaces to that file the more confused I become... > > > Index: arm-tdep.c > > =================================================================== > > RCS file: /cvs/src/src/gdb/arm-tdep.c,v > > retrieving revision 1.47 > > diff -p -r1.47 arm-tdep.c > > *** arm-tdep.c 2002/02/19 13:57:35 1.47 > > --- arm-tdep.c 2002/02/19 19:14:40 > > *************** arm_extract_return_value (struct type *t > > *** 2139,2145 **** > > char *valbuf) > > { > > if (TYPE_CODE_FLT == TYPE_CODE (type)) > > ! convert_from_extended (®buf[REGISTER_BYTE (ARM_F0_REGNUM)], valbuf); > > else > > memcpy (valbuf, ®buf[REGISTER_BYTE (ARM_A1_REGNUM)], > > TYPE_LENGTH (type)); > > Here, unfortunatly, directly pokeing around the regcache buffer (a > parameter) is still the only way to do this. Yep, this is awful, but that's what it has always done there (you quote the old code). > > TYPE_LENGTH (type)); > > *************** arm_store_return_value (struct type *typ > > *** 2256,2270 **** > > { > > if (TYPE_CODE (type) == TYPE_CODE_FLT) > > { > > char buf[MAX_REGISTER_RAW_SIZE]; > > > > ! convert_to_extended (valbuf, buf); > > ! /* XXX Is this correct for soft-float? */ > > ! write_register_bytes (REGISTER_BYTE (ARM_F0_REGNUM), buf, > > ! MAX_REGISTER_RAW_SIZE); > > I think your changes to this function can be rewritten to use > write_register_gen(REGNUM,BUF). And you quote the old code again here. > Need to be careful though. If the code is assuming a floating point > value should be stored across multiple adjacent registers then the code > will need to be broken down into separate explicit writes. I desperately need a high-level overview of how the regcache interface is *supposed* to work in the brave new world (ie without all the legacy interfaces lying around). Let me start by trying to draw a little diagram to explain how I think it might work; then we can expand on that, or re-draw it as appropriate. Lets start the model with four main units. The inferior, the regcache, the MI routines and the tdep support. The interfaces are then as follows: +--------------------------------+ | Inferior | +--------------------------------+ ^ | | | A | v +--------------------------------+ | Regcache | +--------------------------------+ ^ | ^ | | | B | | C | v | v +-------------+ +-------------+ | MI |<==>| Tdep | +-------------+ D +-------------+ That gives us three potential interfaces to the regcache, A, B and C. In addition, there is an interface D, which is effectively the gdbarch vector. Now, as I understand it, interface A is quite straight-forward and consists of three functions: supply_register() collect_register() set_register_cached() [The last of these is needed because a target may be unable to recover some registers at certain times, and may need to tell the regcache that.] This interface is used by the 'nat' code or anything else that talks to a target machine (ie it lies at the callee side of a target_ops vector). However, after that it starts to become fuzzy. The first problem is that it isn't completely clear whether the regcache should contain a raw cache of the physical registers, or some munged view of them. I'd be inclined to argue the regcache should be pretty much a raw cache of the machine registers, and that interface B is therefore bogus (since it can't know how to interpret the information); therefore all accesses to the regcache by MI code should be, at least conceptually, via the tdep code using interface D. Of course, it may be that many targets will have near identical routines for mapping D<->C and there's no reason why that shouldn't be extracted out so that the gdbarch vector can handle it cleanly. So my questions are: Do we have interface B? If so, why? what functions comprise C? and what functions comprise D? > > enjoy, Not a chance :-) R.