From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2946 invoked by alias); 16 Dec 2002 18:56:54 -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 2936 invoked from network); 16 Dec 2002 18:56:53 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Dec 2002 18:56:53 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18O2Ib-0004LN-00; Mon, 16 Dec 2002 14:57:13 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18O0R4-0006Vz-00; Mon, 16 Dec 2002 13:57:50 -0500 Date: Mon, 16 Dec 2002 11:13:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info Message-ID: <20021216185750.GA24656@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DFE1ECD.5080908@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00496.txt.bz2 On Mon, Dec 16, 2002 at 01:43:25PM -0500, Andrew Cagney wrote: > INIT_FRAME_EXTRA_INFO() can throw an error. For instance, due to an > attempt to read from an address specified by PC/FP/SP when that address > is invalid. For such cases, there should still be a current frame (so > that `info registers' works) but it shouldn't unwind any further. > > So again, yes, you'll end up with current-frame -> regs-frame. OK, I follow you now. Hmm... > >>>As for this situation, and the similar one for i386... there are three > >>>unwind functions, to find the previous frame's registers, ID, and PC. > >>>For this case we just want to express a normal function call which > >>>saves no registers; pretty easy. But for i386 I'll want to express > >>>something which initially pushes a register, and then does some work, > >>>pops it, and does more work before returning. > > > >> > >>So you're proposing that the saved-regs code be used to generate a cfi > >>description as well? > >> > >>Interesting. > > > > > >Precisely. When given a function without enough information to > >backtrace through it in the debug info, the prologue scanner could > >implement this new method in order to provide backtraces. It could > >really clear up some messes. > > > >I think it's a promising idea. > > 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. 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer