From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32592 invoked by alias); 2 Jan 2003 21:19:13 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32585 invoked from network); 2 Jan 2003 21:19:10 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by 209.249.29.67 with SMTP; 2 Jan 2003 21:19:10 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18UEcC-0000pi-00; Thu, 02 Jan 2003 17:19:04 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18UCjc-00067M-00; Thu, 02 Jan 2003 16:18:36 -0500 Date: Thu, 02 Jan 2003 21:19:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info Message-ID: <20030102211836.GA23173@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michal Ludvig , GDB Patches References: <3DFE289B.3080904@redhat.com> <20021216193459.GA27215@nevyn.them.org> <3DFE3007.3040100@redhat.com> <20021216201117.GA31474@nevyn.them.org> <3DFF185B.9090806@suse.cz> <3DFF3353.2090803@redhat.com> <20021217151304.GA5778@nevyn.them.org> <3E0057EB.1080104@redhat.com> <20021218153733.GA11738@nevyn.them.org> <3E14A709.9040902@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E14A709.9040902@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-01/txt/msg00032.txt.bz2 On Thu, Jan 02, 2003 at 08:54:33PM +0000, Andrew Cagney wrote: > fde = get_fde_for_addr (context->ra - 1); > > >+ > > >+ if (fde == NULL) > > >+ fde = guess_generic_fde (context->ra - 1); > > > > > > if (fde == NULL) > > > return; > > Just to be clear. The above is the change that I think is wrong. > > Instead of this function `guessing' the source of the FDE, the code > needs to be re-structured so that the caller always supplies a > pre-created FDE. > > That way a dwarf2 cfi frame can call the above function with an FDE > built from the object files debug info, while an artifical frame can > call it with an artifically created FDE. There is no guessing involved. Hold a second here; I don't think we're really communicating on what this change is supposed to do. Look at where that code is: it's in frame_state_for. Its inputs are a CONTEXT and FS (struct frame_state *). The first line in your quote is: fde = get_fde_for_addr (context->ra - 1); I just don't understand what you mean by "the caller supplies an FDE"; this is where we locate the FDE. The caller's got no business knowing what an FDE is. This new mechanism is supposed to handled any code which doesn't have a defined FDE, for which an architecutre-specific (yes) hook can deduce the appropriate FDE from code inspection. These are not "artificial frames". We've got four types of frames that we've been talking about recently: - the magical register frame/inner frame - dummy frames - sigtramp frames - "normal" stack frames caused by compiled code calling other compiled code Maybe there will be others, but notice that all the above are conceptually different kinds of things. These "artifical" frames are just normal frames, where we synthesize the debug information because we didn't have any. It's a mechanism to coalesce things like prologue readers. It is absolutely not a new type of frame. That's why I think this code is in exactly the right place, right now. Are you saying that the CFI code should just be returning, saying "no idea, go away, don't talk to me", and leaving this be? That's all well and good but that way we end up duplicating the whole of the CFI reader. A good long term direction, with appropriate code factoring, but it's hardly practical. > This is part of a long standing problem - it predates dwarf2cf by many > years. Instead of using recursion, people modify debug/target dependent > frame code so that it attempts to directly handle all cases. Cf all the > PC_IN_CALL_DUMMY(frame->next), PC_IN_SIGTRAMP(frame->next) and other > tests scattered through out the -tdep.c code; and the calls to > get_next_frame() in dwarf2cfi.c. The one call to get_next_frame, which parallels init_frame_pc_default. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer