From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23244 invoked by alias); 21 May 2003 15:12:23 -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 23157 invoked from network); 21 May 2003 15:12:22 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 21 May 2003 15:12:22 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 8B7252B2F for ; Wed, 21 May 2003 11:12:14 -0400 (EDT) Message-ID: <3ECB974E.9060902@redhat.com> Date: Wed, 21 May 2003 15:12:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: gdb@sources.redhat.com Subject: cooked regcache -> frame Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00287.txt.bz2 [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