From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13776 invoked by alias); 17 Mar 2003 00:36:22 -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 13741 invoked from network); 17 Mar 2003 00:36:22 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 17 Mar 2003 00:36:22 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18ukVS-0001kC-00 for ; Sun, 16 Mar 2003 20:37:42 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18uic0-0005UY-00 for ; Sun, 16 Mar 2003 19:36:20 -0500 Date: Mon, 17 Mar 2003 00:36:00 -0000 From: Daniel Jacobowitz To: gdb@sources.redhat.com Subject: Re: Lazy get_frame_id() Message-ID: <20030317003620.GB20827@nevyn.them.org> Mail-Followup-To: gdb@sources.redhat.com References: <3E750857.50601@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E750857.50601@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-03/txt/msg00243.txt.bz2 On Sun, Mar 16, 2003 at 06:27:19PM -0500, Andrew Cagney wrote: > Hello, > > At present a frame's ID is computed when the prev frame is created. I'd > like to propose that, instead, for code relying on the new frame > mechanisms, the computation of a frame's ID be delayed until it is > needed - an explicit call to get_frame_id(). > > This will mean that get_prev_frame() is reduced to something like: > > ... perform refuse to unwind checks ... > - this->pc isn't valid? return NULL > - this->id isn't valid? return NULL > ... create the new frame ... > prev = allocate() > prev->pc = frame_pc_unwind (this); > (prev->type, prev->unwind = > (frame_type_from_pc (prev->pc), > find_unwind_find_by_pc (prev->pc)); > ... link it in ... > this->prev = prev; > prev->next = this; > ... return it ... > return prev; > > > Where: > > - frame_pc_unwind(), when applied to the sentinel frame, does not need > to do any prologue analysis and hence shouldn't be a load on the target. > > - frame_type_from_pc(), frame_unwind_find_by_pc() can/should be merged > since they are both using the same PC based tests. > > - the frame ID sanity checks are removed (or only applied when trying to > do the next chain). This I really like. It seems like the right time... > This has two immediatly effects: > > - get_current_frame() is cheap > > - when a back-trace dies with an invalid frame (due to frame ID), it is > possible to examine that invalid frame (previously it wasn't possible). This is a definite improvement. You mean if (for instance) there is a call to error() trying to build the next frame? I've run into this in practice. > It opens up the possibility of, in WFI (infrun.c, et.al.), replacing the > calls: > - PC_IN_SIGTRAMP() > - PC_IN_CALL_DUMMY() > with the equivalent: get_frame_type (get_current_frame ()) == > SIGTRAMP_FRAME et.al. In fact, since the computation would be done > once, this would be less load on the target. > > > What's the fine print? > > It will have the effect of making it very difficult to predict which of > this_id() or prev_register() is called first. The call sequence can > always be forced (if that makes peoples life easier). IMVHO, we should probably force the frame ID before general register unwinding. > ``for code relying on the new frame mechanisms''. The WFI change, for > old architectures, could potentially make them run slower (for old > architectures get_current_frame() forces a prologue analysis). I'm > going to go out on a limb and argue that this is OK. It doesn't break > the old architectures (just degrades them a little :-). On the other > hand, it makes it possible to ratinalize WFI a little. And I agree here too. Mark's making great strides on converting i386 already. I don't have time this month to follow the frame stuff as it evolves, so I've been mostly ignoring it, but I'm willing to try my hand at converting the other architectures I need once it seems to have stabilized. If your port wants performance benefits it has to move forwards! > Anyway, ignoring WFI, any comments on the principle behind this change? I like it. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer