From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25220 invoked by alias); 16 Dec 2002 18:43:37 -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 25193 invoked from network); 16 Dec 2002 18:43:32 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 16 Dec 2002 18:43:32 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6D6F73CBB; Mon, 16 Dec 2002 13:43:25 -0500 (EST) Message-ID: <3DFE1ECD.5080908@redhat.com> Date: Mon, 16 Dec 2002 10:56:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.1) Gecko/20021211 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Michal Ludvig , GDB Patches Subject: Re: [RFA] Artifical dwarf2 debug info References: <3DFBD14C.7090501@suse.cz> <3DFE0741.7020902@redhat.com> <20021216172813.GA18150@nevyn.them.org> <3DFE14D9.7040102@redhat.com> <20021216181104.GA21047@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-12/txt/msg00495.txt.bz2 >> 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. The, in theory, operation: frame_register_unwind (get_next_frame (get_current_frame()), ...) however, they wouldn't be implemented that way. I'm sitting on patch that shows this working. The operation: frame_id_unwind (get_next_frame (current_frame), ...) frame_pc_unwind (get_next_frame (current_frame), ...) are, unfortunatly, more complicated. At their core is DECR_PC_AFTER_BREAK (and why I've not posted that patch). > 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. 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. >> >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. Andrew