From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13747 invoked by alias); 3 Jun 2003 05:47:55 -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 13740 invoked from network); 3 Jun 2003 05:47:55 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 3 Jun 2003 05:47:55 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200] (may be forged)) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id h535lsH22219 for ; Tue, 3 Jun 2003 01:47:54 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id h535lpT23179; Tue, 3 Jun 2003 01:47:51 -0400 Received: from dot.sfbay.redhat.com (dot.sfbay.redhat.com [172.16.24.7]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id h535ln022094; Mon, 2 Jun 2003 22:47:49 -0700 Received: (from rth@localhost) by dot.sfbay.redhat.com (8.11.6/8.11.6) id h535jqr19104; Mon, 2 Jun 2003 22:45:52 -0700 X-Authentication-Warning: dot.sfbay.redhat.com: rth set sender to rth@redhat.com using -f Date: Tue, 03 Jun 2003 05:47:00 -0000 From: Richard Henderson To: Jim Blandy Cc: Andrew Cagney , Mark Kettenis , mludvig@suse.cz, gdb@sources.redhat.com, Alexandre Oliva Subject: Re: dwarf-frame.c question Message-ID: <20030603054552.GD19075@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i X-SW-Source: 2003-06/txt/msg00021.txt.bz2 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? r~