From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30333 invoked by alias); 1 Jul 2003 16:14:33 -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 30242 invoked from network); 1 Jul 2003 16:14:30 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sources.redhat.com with SMTP; 1 Jul 2003 16:14:30 -0000 Received: from nkelseyhome (12-235-58-117.client.attbi.com[12.235.58.117](untrusted sender)) by comcast.net (rwcrmhc12) with SMTP id <2003070116142601400mn04qe>; Tue, 1 Jul 2003 16:14:26 +0000 Message-ID: <007a01c33feb$d4d020e0$0a00a8c0@nkelseyhome> From: "Jafa" To: "Andrew Cagney" , References: <09a601c33f6e$b05a3480$0a02a8c0@scenix.com> <20030701034232.GB3434@nevyn.them.org> <00d001c33f8f$8cc48b30$0a00a8c0@nkelseyhome> Subject: Re: Frame handling Date: Tue, 01 Jul 2003 16:14:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 X-SW-Source: 2003-07/txt/msg00022.txt.bz2 Hi Andrew >>> I'm not sure I understand the question. >> I agree, and I don't think it will make much difference eitehr way, however >> I was just thinking that it would be a whole lot easier to explain these >> functions... >> >Um, this is still dangling. Can you please express your question using >terminology consistent with the frame unwind code. Sorry, it was a bit of a ramble :-) Avr and d10v ports both have function avr/d10v_frame_unwind_cache which figure out everything about a frame but are internal functions. The frame-base and frame-unwind APIs provides a machanism to register functions - struct frame_base { ... frame_this_base_ftype *this_base; frame_this_locals_ftype *this_locals; frame_this_args_ftype *this_args; }; struct frame_unwind { ... frame_this_id_ftype *this_id; frame_prev_register_ftype *prev_register; }; All five of these functions work on the principle of "given this frame, figure out xxx information of the caller's frame" and are passed a pointer to the next_frame (child frame). For example, "given this frame, figure out where the arguments start of the caller's frame." I would like to suggest the following: - _frame_unwind_cache functions to be registered as part of the frame-unwind API. - GDB to call _frame_unwind_cache once each time it wants to go back one frame. - next_frame parameter removed from all five functions above. - remove call to _frame_unwind_cache function from the port-specific implementations of the five functions above. At a minimum the _frame_unwind_cache function could store the next_frame parameter and the five functions above could get next_frame from this_base_cache parameter. In practice many (most?) ports will do a _frame_unwind_cache function that figures out everything about the frame in one step and the five fucntions above will simply read out of the this_base_cache. Advantages: - Eliminates some common code from all ports. (call to _frame_unwind_cache inside each function). - Eliminates next_frame parameter to these functions. - Easier to explain/understand the API because you only have to think about one frame level. - If a particular port wants the next_frame parameter to search within each of the five functions then they can save the next_frame parameter themselves (1 line of code) and it is exactly the same. I would be happy to provide a patch to look at if that would help explain and fuel the discussion. Thanks Nick