From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24477 invoked by alias); 3 Jun 2003 06:32:04 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 24410 invoked from network); 3 Jun 2003 06:32:02 -0000 Received: from unknown (HELO zenia.red-bean.com) (12.223.225.216) by sources.redhat.com with SMTP; 3 Jun 2003 06:32:02 -0000 Received: from zenia.red-bean.com (localhost.localdomain [127.0.0.1]) by zenia.red-bean.com (8.12.5/8.12.5) with ESMTP id h536ViQX002750; Tue, 3 Jun 2003 01:31:44 -0500 Received: (from jimb@localhost) by zenia.red-bean.com (8.12.5/8.12.5/Submit) id h536UukE002745; Tue, 3 Jun 2003 01:30:56 -0500 To: Richard Henderson Cc: Andrew Cagney , Mark Kettenis , mludvig@suse.cz, gdb@sources.redhat.com, Alexandre Oliva Subject: Re: dwarf-frame.c question References: <3ED381CB.5050207@suse.cz> <200305291544.h4TFi7aL031832@elgar.kettenis.dyndns.org> <3ED66564.1020506@redhat.com> <200305292222.h4TMMmGm000694@elgar.kettenis.dyndns.org> <3ED693F5.9040108@redhat.com> <3ED7BFD1.7060902@redhat.com> <20030603054552.GD19075@redhat.com> From: Jim Blandy Date: Tue, 03 Jun 2003 06:32:00 -0000 In-Reply-To: <20030603054552.GD19075@redhat.com> Message-ID: User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-06/txt/msg00022.txt.bz2 Richard Henderson writes: > On Mon, Jun 02, 2003 at 07:03:56PM -0500, Jim Blandy wrote: > > The DW_CFA_GNU_unwind_from_noreturn instruction indicates that the > > current set of rules applies only when the current location was > > reached by unwinding a frame called by this one, not when it was > > reached from elsewhere in the subroutine. > > > > The DW_CFA_GNU_unwind_from_noreturn instruction also creates a new > > table row whose location value is the same as this one; this > > latter row applies when the given location was reached from > > elsewhere in the same subroutine. > > So the effect would be that in the "normal" case we'd continue > evaluating CFA opcodes as usual until we get to an advance that > moves past the PC. > > The debugger, on the other hand, would have to know that we are > unwinding from deeper in the call stack, and set a special flag > that would stop at the new note? Yeah, that's the idea. But I did think of a simpler way to fix this, which wouldn't require any new Dwarf at all: Since we're unwinding a frame which will never really be unwound, we can have that do anything we want. So, if a function never returns, why not have the compiler emit CFI that restores the state just *before* the call insn was executed, not after it returns? The unwound PC would point at the call insn itself. (That's what the user expects to see anyway.) The other registers would be as appropriate before the call was made. You unwind from there as usual. I feel like I'm missing something. Does the compiler have enough info to do this? ("No, the compiler doesn't really have enough info to emit CFI at all, but we do our best, and that's usually okay"?) It would be weird if you used "return" to artificially pop the frame and continue. But that's a bogus thing to do anyway --- the return address is garbage, so who knows where you're resuming? If the function ends with a "call" to 'abort', followed by no more code, then "return" might just start running at the entry point of the next function, for goodness' sake. None of the proposals here will make that do something sensible, so is this behavior really any more wrong?