From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gnu-gabi-return-97-listarch-gnu-gabi=sourceware.org@sourceware.org>
Received: (qmail 97046 invoked by alias); 21 Oct 2016 13:48:34 -0000
Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gnu-gabi.sourceware.org>
List-Post: <mailto:gnu-gabi@sourceware.org>
List-Help: <mailto:gnu-gabi-help@sourceware.org>
List-Subscribe: <mailto:gnu-gabi-subscribe@sourceware.org>
Sender: gnu-gabi-owner@sourceware.org
Received: (qmail 96252 invoked by uid 89); 21 Oct 2016 13:48:30 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level: 
X-HELO: mx2.suse.de
X-Virus-Scanned: by amavisd-new at test-mx.suse.de
Date: Fri, 01 Jan 2016 00:00:00 -0000
From: Michael Matz <matz@suse.de>
To: Florian Weimer <fweimer@redhat.com>
cc: "H.J. Lu" <hjl.tools@gmail.com>, gnu-gabi@sourceware.org
Subject: Re: [PATCH] Make _Unwind_GetIPInfo part of the ABI
In-Reply-To: <alpine.LSU.2.20.1610211521400.5714@wotan.suse.de>
Message-ID: <alpine.LSU.2.20.1610211546460.5714@wotan.suse.de>
References: <dc8948e5-05e9-1ce9-8279-34fd70d10fa7@redhat.com> <alpine.LSU.2.20.1610211448060.5714@wotan.suse.de> <fd505b01-3f78-b0ea-6afa-3e3e713b7e54@redhat.com> <alpine.LSU.2.20.1610211521400.5714@wotan.suse.de>
User-Agent: Alpine 2.20 (LSU 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
X-SW-Source: 2016-q4/txt/msg00016.txt.bz2

Hi,

On Fri, 21 Oct 2016, Michael Matz wrote:

> > On 10/21/2016 02:58 PM, Michael Matz wrote:
> > > +This function returns the same value as \code{\_Unwind\_GetIP}.  In
> > > +addition, the argument \code{ip\_before\_insn} must not be not null, and
> > > +\code{*ip\_before\_insn} is updated with a flag which indicates whether
> > > +the returned pointer is at or after the first not yet fully executed
> > > +instruction.
> > 
> > I think this is rather misleading.  On x86_64, the location of the IP 
> > value is the same for calls and asynchronous signals: it always points 
> > to the next instruction to be executed.
> 
> No, that's simply wrong.

Or rather, it isn't wrong, it's indeed pointing to the instruction to be 
executed next after return from handler, as always.  But that's not the 
important thing for unwinding: what you're interested in is the 
instruction that _caused_ the interruption, and for that what I said 
applies.


Ciao,
Michael.