From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20390 invoked by alias); 1 Jul 2003 17:59:59 -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 20376 invoked from network); 1 Jul 2003 17:59:57 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by sources.redhat.com with SMTP; 1 Jul 2003 17:59:57 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 665D42B5F; Tue, 1 Jul 2003 13:59:45 -0400 (EDT) Message-ID: <3F01CC11.4090607@redhat.com> Date: Tue, 01 Jul 2003 17:59: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: Jafa Cc: gdb@sources.redhat.com Subject: Re: Frame handling References: <09a601c33f6e$b05a3480$0a02a8c0@scenix.com> <20030701034232.GB3434@nevyn.them.org> <00d001c33f8f$8cc48b30$0a00a8c0@nkelseyhome> <007a01c33feb$d4d020e0$0a00a8c0@nkelseyhome> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-07/txt/msg00024.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." (To clarify something, they work on the basis of ``given the next frame''. They must assume that ``this frame'' does not exist - an attept to call get_prev_frame (next_frame) would be wrong) (See my e-mail to daniel) Anyway, the old code did similar to what you suggest. Because the cache initialize was disconnected from the specific request, people were never sure how much to initialize and when. As a consequence, it was done randomly, using random techniques. GDB (core, target and architecture) is littered with calls like: if (!frame->extra_info) INIT_FRAME_EXTRA_INFO and if (!frame->saved_regs) INIT_FRAME_SAVED_REGS So while the line: cache = get_frame_cache (next_frame, this_cache); might seem a pain, its far less of a pain than the old code that had very complicated cache initialization rules. At least it is clear where the buck stops - the entire problem falls squarely on the sholders of the unwinder. > I would like to suggest the following: > - _frame_unwind_cache functions to be registered as part of the > frame-unwind API. BTW, two, and not one initialize methods would need to be added: one for frame-unwind, and one for frame-base. A problem from the old code was the plithera of unwind methods, hmm. > - 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. Zero benefit. Every init frame cache method will have (not could) to store next_frame in the cache. Without it, the frame code couldn't access memory or registers. Burrying the frame (hiding it in a cache) would make debugging gdb a royal pain. At present the applicable frame is made explicit as it is a parameter. Andrew