From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29664 invoked by alias); 21 May 2003 20:03:03 -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 29379 invoked from network); 21 May 2003 20:03:01 -0000 Received: from unknown (HELO zenia.red-bean.com) (12.222.151.100) by sources.redhat.com with SMTP; 21 May 2003 20:03:01 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h4LKAfFq007257; Wed, 21 May 2003 15:10:41 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h4LKAfNi007253; Wed, 21 May 2003 15:10:41 -0500 To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: cooked regcache -> frame References: <3ECB974E.9060902@redhat.com> From: Jim Blandy Date: Wed, 21 May 2003 20:03:00 -0000 In-Reply-To: <3ECB974E.9060902@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-05/txt/msg00290.txt.bz2 The frame seems like the right thing to me, too. Andrew Cagney writes: > [To think out loud - I'm refering to how GDB should work, not how it > does work :-)] > > Ref: [RFA]: gdbarch FETCH_POINTER_ARGUMENT > http://sources.redhat.com/ml/gdb-patches/2003-05/msg00329.html > Ref: [multi-arch] The frame as the global parameter (long, important), > http://sources.redhat.com/ml/gdb/2001-02/msg00335.html > > > The [original] FETCH_POINTER_ARGUMENT code does things like: > > - return read_register (3 + i); > > and > > - CORE_ADDR stack = read_register (SP_REGNUM); > - return read_memory_unsigned_integer (stack + (4 * (i + 1)), 4); > > that is, it relies on global state to determine the values. Global > state is bad m'kay :-) > > There are a number of ways to fix this. All involve the addition of a > context parameter, the problem though is which one. > > - the regcache > While the most obvious it only solves half the problem. The regcache > can provide the inner most registers, but not the memory. Adding > memory access methods to the regcache ``feels wrong''. Also, the > regcache limits things to the inner most frame. > > - the target > But a target can have multiple threads > > - the frame > A frame has registers, memory, architecture, and a thread > > - the thread > A thread has registers and memory, architectures and > frames. Unfortunatly, that was multiple frames (selected, current, > ...) and multiple architectures (potentially one per frame ...) so > while it looks good it is really only useful for an operation that > applies to the inner most frame :-/ > > Hence, I think, increasingly the frame, and not the regcache or thread > should be the context parameter of choice (note that this idea isn't > new, it's just becomming more visible, ref above). > > But isn't a frame creation expensive? After all, the last thing WFI > (the state machine that handles things like single step, and calls > this code) needs is an expensive frame create operation. Fortunatly, > frame creation is no longer expensive - on up-to-date architectures, > it is a very cheap operation. > > What next? > > I guess I'll (unless someone else wants to :-) be re-visting all the > architecture functions parameterized with a regcache to see if/where > they should be re-parameterised with a frame. Fortunatly, unlike the > registers[] to regcache conversion, this change would be > mechanical. The obvious candiates for review are those that are > reading reading register values from the inner most frame === the > regcache. > > The other problem is register writes, and that, I think, deserves a > separate post. > > Andrew