From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15360 invoked by alias); 16 Dec 2002 20:10:23 -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 15348 invoked from network); 16 Dec 2002 20:10:21 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Dec 2002 20:10:21 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18O3Rg-0004UE-00; Mon, 16 Dec 2002 16:10:40 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18O1a9-0008FK-00; Mon, 16 Dec 2002 15:11:17 -0500 Date: Mon, 16 Dec 2002 12:42:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info Message-ID: <20021216201117.GA31474@nevyn.them.org> Mail-Followup-To: Andrew Cagney , Michal Ludvig , GDB Patches References: <3DFBD14C.7090501@suse.cz> <3DFE0741.7020902@redhat.com> <20021216172813.GA18150@nevyn.them.org> <3DFE14D9.7040102@redhat.com> <20021216181104.GA21047@nevyn.them.org> <3DFE1ECD.5080908@redhat.com> <20021216185750.GA24656@nevyn.them.org> <3DFE289B.3080904@redhat.com> <20021216193459.GA27215@nevyn.them.org> <3DFE3007.3040100@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DFE3007.3040100@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00502.txt.bz2 On Mon, Dec 16, 2002 at 02:56:55PM -0500, Andrew Cagney wrote: > > >>>If I'm scanning this code correctly, all we would need to do would be > >>>to connect set_unwind_by_pc to the CFI machinery. No, it's more > >>>complicated than that, we still call both FRAME_CHAIN and > >>frame_pc_unwind; > >>>I'm not entirely clear on how frame_saved_regs_id_unwind works. > >>>Similarly in get_prev_frame. > > > >> > >>FRAME_CHAIN is going away. > >> > >>The steps are broadly: > >> pc = pc-unwind (next_frame) > >> if (not an edge case like dummy frame where the id doesn't need to > >> be unwound because the frame can be identified using the callee's ID) > >> id = id-unwind (next_frame); > >> create frame from pc/id setting new unwind methods using pc. > >>(frame_saved_regs_id_unwind is there to keep code that just implements > >>frame chain working.). > > > > > >Great! > > > > > >>>But what I'd like to see is something like you've sketched above. > >>>Probably check first for dummy frame, then for sigtramp frame, then for > >>>CFI frame, and then fall back to the defaults. > > > >> > >>Yes. Should the choices/order be hardwired or specified by the > >>architecture though? I.e., iterate over a list of possible frames that > >>are specified by the architecture. > > > > > >Hmm, I'm not sure. Do we have any architectures that would want to > >specify their own frame types? In such a way that using this CFI > >approach wouldn't suffice? > > Well, I'd not want to be the one enabling CFI on all architectures. > That code needs some serious cleanups. Yes. I'd like to start turning this on for other architectures, and I suspect it'll come on for i386 when Mark K. really gets his teeth into bringing that together with the x86-64 port. Hopefully it will clean up over time. > As for own frame types, a SIGTRAMP frames are one case. Hmm, good point, that could be handled by an architecture-dependent list of frame types. > >>The catch is that it needs to unwind the PC before anything else. That > >>way it can correctly set the type. Like I said, patch for that pending. > > > > > >Right. I really appreciate all your cleanups in this area. I have > >some work to do on FRAME_CHAIN_VALID but I'll sit on it for a while, > >until I see what this looks like when you're done revamping the > >unwinders. (That's the backtrace-to-or-through-main conversation from > >some months ago.) > > > >Back to the patch at the beginning of this thread - do you think this > >view of fake CFI information is feasible? Any comments on Michal's > >patch? > > It's feasible. It may long term solve another problem. Apparently GDB > needs to generate, at run time, debug info for things like Java. It may > also be easier to handle this case by implementing direct functions and > not going via CFI. > > That actual code, though, is a mess. It is adding another edge case to > code that shouldn't have to handle anything at all. Where's the case you're concerned about - are you refering to code in the tdep file or in dwarf2cfi.c? > BTW, exactly is the difference between a prologueless and frameless > function? The prologue case appears to be checking for a push -> the > reverse of frameless. The patch doesn't talk about frameless functions particularly - it checks for _has_prologue, and generates an FDE based on whether it does or not... -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer