From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6409 invoked by alias); 16 Dec 2002 18:10:08 -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 6389 invoked from network); 16 Dec 2002 18:10:06 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 16 Dec 2002 18:10:06 -0000 Received: from nevyn.them.org ([66.93.61.169] ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 18O1ZL-0004G7-00; Mon, 16 Dec 2002 14:10:27 -0600 Received: from drow by nevyn.them.org with local (Exim 3.36 #1 (Debian)) id 18Nzho-0005cl-00; Mon, 16 Dec 2002 13:11:04 -0500 Date: Mon, 16 Dec 2002 10:17:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info Message-ID: <20021216181104.GA21047@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DFE14D9.7040102@redhat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-12/txt/msg00488.txt.bz2 On Mon, Dec 16, 2002 at 01:00:57PM -0500, Andrew Cagney wrote: > > >That's right. > > > > > >>If that is the case then I don't think this is either necessary or > >>correct. A `struct frame_info' allows frame specific unwind functions - > >>at present only dummy-frame and saved-regs-frame versions are > >>implemented, however the next ones to implement are cfi-frame (unwind > >>using CFI info) and regs-frame (unwind using the register cache). > >> > >>For your problem, wouldn't it be better to, instead of creating fake CFI > >>info, implement custom frame unwind functions that handle your case? > > > > > >Hrm. What do you mean by regs-frame? If it's for the current frame > >wouldn't that be a frame which just doesn't unwind? > > A frame that gets the saved registers from the register cache. As for uses: > - an inner-most frame that for some reason doesn't unwind (i.e., > create_new_frame() barfs). > - the frame that is inner to `current frame'. I'm confused again :) "Current frame" is one which does not unwind, right? No saved PC, no saved registers. The concepts are meaningless. Its frame ID corresponds (very) loosely to the current stack pointer. This would be frame #0 in a backtrace. There's nothing inside of it. Or are you saying that the innermost frame is this special regs-frame, and the current frame (still #0) is outside of that? OK, that jives with some things I remember you describing earlier. Makes sense now. I don't see what you mean by "doesn't unwind", since we always start with having the current frame (i.e. there would be at least two) but I think I'm back on your page again. > >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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer