From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60099 invoked by alias); 21 Oct 2016 18:51: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 60088 invoked by uid 89); 21 Oct 2016 18:51:08 -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=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=Hx-languages-length:1527, H*r:sk:gnu-gab X-Spam-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qk0-f181.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=dZG7Mf3Dywm7OsnxOWeDDUf3mf+1pgONYVfZGXkYnEc=; b=LLEBSDNLMcdSiITzBJQXC/1CPViVcxm2t71NDrJog6IbaJShSkRbVZb+mvaVul8u8D 9f/5OOMWwcfEas1aIJ0sdwmFyHQJPVu+yMhwDslXcJmBT33TF/z2pF6RoRNwyucWTNbw KTNRe8o9tU67Q3v6Ost9uuw9lRxnvbWEqSJKDivi+FScdOlbIipJKSCkNWPeRzz0NwfS KtS+q+YFStTQSoa8l15kZx7es9+a1dn0PIyzBjQOP3IH7xOohZ8Kxb7/gxyrZErPK2r5 mJX+wcNJkQ4ZfAR0sLlb5RPPtrIleWWiC8W3/44RYDyOsUHN9XRAQrs2jkf4WSCsn033 EG3A== X-Gm-Message-State: ABUngvciE+GbJUpnA9KmaDoyTt6wm7HjR0f8aWGT2KJsp3eCt6J3gtHFOXJ1QE97tfWw41VD X-Received: by 10.55.209.26 with SMTP id s26mr2575602qki.24.1477075865777; Fri, 21 Oct 2016 11:51:05 -0700 (PDT) Subject: Re: [PATCH] Make _Unwind_GetIPInfo part of the ABI To: Michael Matz , Florian Weimer References: Cc: "H.J. Lu" , gnu-gabi@sourceware.org From: Carlos O'Donell Organization: Red Hat 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.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-q4/txt/msg00020.txt.bz2 On 10/21/2016 09:48 AM, Michael Matz wrote: > 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. When you say "after the first not yet fully executed instruction" do you mean "immediately after" or "some time after?" On 32-bit hppa there is a delayed branch slot which means that after a call you are two instructions past the call. On 32-bit ARM you also have IP being two instructions beyond the call at any point in time due to pipelining. This would also mean the current code in gcc/libgcc/unwind-c.c needs to have a target hook for it to be right? -- Cheers, Carlos.