From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21286 invoked by alias); 30 Mar 2007 18:41:12 -0000 Received: (qmail 21269 invoked by uid 22791); 30 Mar 2007 18:41:12 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 Mar 2007 19:41:07 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 528B94B267; Fri, 30 Mar 2007 13:41:05 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id 78D384B262; Fri, 30 Mar 2007 13:40:52 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.63) (envelope-from ) id 1HXM1r-00074H-Ss; Fri, 30 Mar 2007 14:40:51 -0400 Date: Fri, 30 Mar 2007 18:41:00 -0000 From: Daniel Jacobowitz To: Michael Eager Cc: Jim Blandy , gdb@sources.redhat.com Subject: Re: GDB Documentation and Request for Help Message-ID: <20070330184051.GA26862@caradoc.them.org> Mail-Followup-To: Michael Eager , Jim Blandy , gdb@sources.redhat.com References: <460D46B7.10902@eagercon.com> <460D565F.3070307@eagercon.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <460D565F.3070307@eagercon.com> User-Agent: Mutt/1.5.14+cvs20070313 (2007-03-13) X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-03/txt/msg00343.txt.bz2 On Fri, Mar 30, 2007 at 11:26:39AM -0700, Michael Eager wrote: > Jim Blandy wrote: > >If you post here, I think people would be happy to explain what's > >current and what isn't. I'll watch for your messages. > Thanks. I think that my questions are not very specific and > it would be better to go through the Target Arch chapter > and mark it up. > But here goes: what did FRAME_INIT_SAVED get replaced by? It got replaced by an entirely demand driven system. There's only two entry points: this_id and prev_register. Every registered unwinder provides both. > Or, the much more general question: when the target hits a > breakpoint, where are the registers read and how does the > current frame get initialized with a frame pointer? (I've > stepped thru normal_stop, and I know it must be somewhere > nearby, but I've not found it.) The old model required explicitly setting up the frame, but nowadays that isn't true. What happens is that the frame cache is cleared by a call to reinit_frame_cache. The next time someone says get_current_frame (), they get two things: - A sentinel frame at "level -1". This has no particularly useful ID, and a prev_register method that reads from the current register cache. - An all new frame at level 0. This doesn't have an unwinder yet; it's just a shell. When you ask for a register belonging to the current frame, frame.c goes up to the next frame (the sentinel frame) and uses its prev_register method. When you ask for the current frame's ID, or for something below it, then frame.c finds a registered unwinder that knows how to handle that frame. Usually this_id and prev_register share a common cache, and the first time either of them is called they call a cache initialization function which does whatever necessary. For instance, parsing the prologue, or reading DWARF unwind tables. (Of course, doing less work up front is OK too and that's something I plan to look into - along with better caching. The whole infrastructure is designed to be lightweight, but it isn't always.) -- Daniel Jacobowitz CodeSourcery