From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2279 invoked by alias); 8 Mar 2003 16:11:19 -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 2269 invoked from network); 8 Mar 2003 16:11:18 -0000 Received: from unknown (HELO localhost.redhat.com) (24.157.166.107) by 172.16.49.205 with SMTP; 8 Mar 2003 16:11:18 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id BA2422A9C; Sat, 8 Mar 2003 11:11:04 -0500 (EST) Message-ID: <3E6A1618.5000104@redhat.com> Date: Sat, 08 Mar 2003 16:11:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mark Kettenis Cc: gdb-patches@sources.redhat.com, brobecker@act-europe.fr, mludvig@suse.cz Subject: Re: [i386newframe] New branch References: <200303081233.h28CXiex040572@elgar.kettenis.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00190.txt.bz2 > Per Andrews suggestion, I just created a new branch, and checked in > the attached on it. This stuff works for me on > i386-unknown-freebsd4.7. Interix and x86-64 are almost certainly > broken on the branch. Let's fix those targets and merge this into > mainline when Andrew is finished diddling with the interfaces :-). s/diddling/deleting/ > +{ > + /* FIXME: kettenis/20030302: I don't understand why the cache isn't > + already initialized. */ > + struct i386_frame_cache *cache = i386_frame_cache (frame, cachep); > + On the branch, while the frame code notionally uses the sequence: pc = frame_pc_unwind(next); id = frame_id_unwind(next); it expands to: prev->pc = next->unwind->prev_register (next->next, &next->prologue_cache, PC_REGNUM); prev->id = prev->unwind->this_id (next, &prev->prologue_cache); So while the PC is unwound first, it is the ID unwind call that is first to see prev's uninitialized prologue cache. Thinking about it, the new frame's PC can be determined solely from unwound register values. For the ID, however, the prev's frame's prologue first needs to be examined to determine, for instance, which register from the next frame needs to be unwound. (the mainline doesn't do this). Andrew