From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16703 invoked by alias); 14 Mar 2003 16:19:47 -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 16639 invoked from network); 14 Mar 2003 16:19:46 -0000 Received: from unknown (HELO localhost.redhat.com) (66.30.197.194) by sources.redhat.com with SMTP; 14 Mar 2003 16:19:46 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9F24C2B11; Fri, 14 Mar 2003 11:19:44 -0500 (EST) Message-ID: <3E720120.9060302@redhat.com> Date: Fri, 14 Mar 2003 16:19: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 , mludvig@suse.cz Cc: gdb-patches@sources.redhat.com Subject: Re: [offbyone RFC] Merge i386newframe References: <3E6FAF64.7070304@suse.cz> <3E70D673.1040504@redhat.com> <200303132246.h2DMk7pH013325@elgar.kettenis.dyndns.org> <3E71F9B4.5000504@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00322.txt.bz2 > If the previous frame's direction flag should have been reset then the register unwind code should have done that (wonder if dwarf2cfi is powerful enough to specify this). > > I felt that it is somehow different from a "saved" registers. But > your phrasing makes me believe it's more correct to reset from the > register unwind code. > > I don't think it is any different. For: > > (gdb) up > Frame #1 foo() > (gdb) info register psw > > to work correctly, the register unwind code will need to zap that bit. Otherwize GDB will mis-represent the value of the PSW in the calling frame. > > I think there is still going to be a problem in the CFI unwinder. The CFI spec as the `architectural' register unwind rule as a loop-hole. Something related to that may need to be added. Wonder if GCC even thought to generate it. Hmm, the throw/catch code must have done something .... Thinking about this some more, a generic pop function won't work. Consider the frames: - sentinel - normal - sigtramp - dummy It's only when unwinding a normal frame that that PSW bit should be zapped. For all the others the PSW value of the callee was hopefully completly saved by the caller. Andrew