From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12308 invoked by alias); 30 Mar 2007 21:14:54 -0000 Received: (qmail 12133 invoked by uid 22791); 30 Mar 2007 21:14:53 -0000 X-Spam-Check-By: sourceware.org Received: from shell4.BAYAREA.NET (HELO shell4.bayarea.net) (209.128.82.1) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 30 Mar 2007 22:14:50 +0100 Received: (qmail 2329 invoked from network); 30 Mar 2007 14:14:48 -0700 Received: from 209-128-106-254.bayarea.net (HELO ?192.168.20.7?) (209.128.106.254) by shell4.bayarea.net with SMTP; 30 Mar 2007 14:14:48 -0700 Message-ID: <460D7DC7.1050803@eagercon.com> Date: Fri, 30 Mar 2007 21:14:00 -0000 From: Michael Eager User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Jim Blandy CC: gdb@sources.redhat.com Subject: Re: GDB Documentation and Request for Help References: <460D46B7.10902@eagercon.com> <460D565F.3070307@eagercon.com> <20070330184051.GA26862@caradoc.them.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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/msg00345.txt.bz2 Jim Blandy wrote: > Daniel Jacobowitz writes: >> 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. > > Michael, your question suggests that you're looking at some code in > your old port, and trying to figure out where it goes in your new > port. I would find that a very hard question to answer if I were in > your shoes. Instead, start by reading frame-unwind.h and having your > foo_gdbarch_init function call frame_unwind_append_sniffer with a > structure containing appropriate functions, written from scratch. > > In other words, you may be able to use the old port to understand how > your target works, but you'll need to decide afresh how to express > that understanding in the new arch description framework. That's exactly the approach I'm taking. > (Having worked on both, I think the new frame system is *much* nicer > to work with, and more reliable. So your efforts won't be wasted.) I'm sure that it is. It's just not documented. Reading code from other targets to figure out what's needed is, well, challenging. I'll take another look at frame-unwind.h. -- Michael Eager eager@eagercon.com 1960 Park Blvd., Palo Alto, CA 94306 650-325-8077