From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20779 invoked by alias); 16 Dec 2002 19:34:05 -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 20767 invoked from network); 16 Dec 2002 19:34:02 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Dec 2002 19:34:02 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18O2sY-0004PD-00; Mon, 16 Dec 2002 15:34:22 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18O112-000787-00; Mon, 16 Dec 2002 14:35:00 -0500 Date: Mon, 16 Dec 2002 11:57:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info Message-ID: <20021216193459.GA27215@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DFE289B.3080904@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00500.txt.bz2 On Mon, Dec 16, 2002 at 02:25:15PM -0500, Andrew Cagney wrote: > > >> > >>Need to figure out how/were this should tie into the rest of the frame > >>structure. The CFI code is not exactly integrated into the mainstream. > >> > >>Here, the key function is get_prev_frame() where GDB first unwinds the > >>PC and then uses that to determine what is needed to unwind/create the > >>rest of the frame. It could easily read: > >> > >> if (pc in dummy-frame) > >> create dummy frame; > >> else if (pc in cfi frame) > >> create cfi frame; > >> else if (pc in something else) > >> create some other frame; > >> > >>or even: > >> > >> while (frame in known unwind types) > >> if (frame and pc match) > >> return create that frame; > >> > >>that is, a target will support a number of frame types, each identified > >>using the PC. > > > > > >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? > 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? -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer