From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6565 invoked by alias); 21 Oct 2016 13:08:09 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 6537 invoked by uid 89); 21 Oct 2016 13:08:06 -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_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1152, consequence X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_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: mx1.redhat.com Subject: Re: [PATCH] Make _Unwind_GetIPInfo part of the ABI To: Michael Matz References: Cc: "H.J. Lu" , gnu-gabi@sourceware.org From: Florian Weimer Message-ID: Date: Fri, 01 Jan 2016 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Fri, 21 Oct 2016 13:08:04 +0000 (UTC) X-SW-Source: 2016-q4/txt/msg00014.txt.bz2 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. There are no partially executed instructions. The difference that if we unwind through a call which has not yet returned, the caller is assumed to be still within the exception handling region in which the call instruction is located. This is the consequence of the desired exception handling semantics of a non-returned function call. It is not directly related to the instruction pointer value returned by _Unwind_GetIPInfo. This is different for the signal case. There, the instruction pointer directly determines the active exception handling region. Florian