From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32561 invoked by alias); 21 Oct 2016 18:37:40 -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 32544 invoked by uid 89); 21 Oct 2016 18:37:39 -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.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=H*r:sk:gnu-gab, H*RU:209.85.220.195, Hx-spam-relays-external:209.85.220.195, H*Ad:U*matz X-Spam-Status: No, score=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS 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-f195.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jNffFEf1pnyTRM475qOlUcVyR8jq8WGUsyJYIwDpmdA=; b=ohx8mp40TY8QntYwYZCJ9w3vInuFXz1ujcR7LCxbNME7rVOOn9NWwcdmaATQFCkxPK Y9EUITlruKhMDloU+QB8FLI8t2OPPUj/GV/YRsPvWBfRwEAaQuggwQe21ssjju5lOndF fmqh2XPSOq9bZ2+++eCUTlZTidLowQKrhr2nH5650VdXziybDM9Q6YBE/23zTLisYyJE 6FM1dl3FbfboyLhtYs5Iq5Rie1JtjyfXUK/eZzEfvZ7W4iJ1fcfceWXn2n5tzooFsb9c SI1wob1OkIr46x+7W3xK6M0vNo1iDqvNBwe0Y8BF/J76IjKTya8lbSNjr6CiyOM9ZcmA NQDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jNffFEf1pnyTRM475qOlUcVyR8jq8WGUsyJYIwDpmdA=; b=kzFdl0R9FeEtueSeEuFpeLxeQHRWlR8AVo0APBnCTEaG/gLkK8PyBWHBeyggtaW/gc NB80mTgbS6PdBxTIWlJrpCwvgZRmxbwtmpz2kRhL1os40VcVgcGobDWXuq8EG6jHevFE WWVKlN7BYx8r1aaMsuxQ675DVbaqcL1YzJ77ZR1TGeeOFmqmEHBJyYzgDqKXIvM4q86j D3y4lN9lvvcwD03PoBsIRvQ2vtKzBYCp0em3JVZoHJLR26P8H7NnUDOiFBsWEzFiib3a 9kUGNdIvOI2WegZbYF3azO6FCqrN6TCdmD8cGfbjWRkXLFM81gqPCKt9oL21s36ELjDE k6BA== X-Gm-Message-State: ABUngvcKDlD6KYq5PCJK+f1h+/6TtuaTzBjZn+4h3ldvviVL1c8ccm36pKl8X1Zg6R4hNiCOrQKHv7y0DKejiA== X-Received: by 10.55.189.132 with SMTP id n126mr2852995qkf.275.1477075056828; Fri, 21 Oct 2016 11:37:36 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: "H.J. Lu" Date: Fri, 01 Jan 2016 00:00:00 -0000 Message-ID: Subject: Re: [PATCH] Make _Unwind_GetIPInfo part of the ABI To: Florian Weimer Cc: Michael Matz , gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q4/txt/msg00019.txt.bz2 On Fri, Oct 21, 2016 at 11:11 AM, Florian Weimer wrote: > On 10/21/2016 03:45 PM, Michael Matz wrote: >> >> Hi, >> >> On Fri, 21 Oct 2016, Florian Weimer 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. The saved instruction pointer points _at_ the >> instruction causing the fault for faults, and _after_ the instruction for >> traps. Traps are things like single-stepping, breakpoints or INTO. Most >> other interrupts are faults or aborts (the latter being imprecise and >> hence can't be restarted anyway). >> >> For calls the saved instruction pointer always points to after the call >> and hence can be handled like a trap for unwinding purposes. > > > Oh, then we are dealing with four different things: Calls, asynchronous > signals (like the internal SIGCANCEL signal, which is how came to this > topic), faults, and traps. > > Using your terminology, traps are like calls (IP adjustment needed). An > SIGCANCEL signal is like a fault because no IP adjustment is allowed. The > GCC unwinders currently treat all the signals the same, which causes it to > use the wrong handler region for traps. > >>> 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. >> >> >> Unwinding through one call or one trap is the same. The interesting >> instruction is the one ending right before the reported IP. > > > Agreed. > >> Except for those situations where it doesn't, for which this function was >> introduced to start with, in order to be able to differ between those >> (basically the kernel needs to mark the signal frame as being the result >> of a fault or a trap, and GetIPInfo uses this to set the flag). > > > It's not really clear to me how the glibc unwinders tell traps from faults. > > Florian We can set signal_frame to 0 for SIGCANCEL? -- H.J.