From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 128934 invoked by alias); 21 Feb 2019 15:55:14 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 128909 invoked by uid 89); 21 Feb 2019 15:55:13 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=on, Hx-languages-length:2997, supplier, H*c:alternative X-HELO: mail-it1-f182.google.com Received: from mail-it1-f182.google.com (HELO mail-it1-f182.google.com) (209.85.166.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Feb 2019 15:55:11 +0000 Received: by mail-it1-f182.google.com with SMTP id z124so23568958itc.2 for ; Thu, 21 Feb 2019 07:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=undo-io.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=srxXQZXwMnsdmOjcwnEt0W1R+H4m9P25HBWSojZCkYc=; b=YJoH/TXCxeDHWfzmvXFuGnGZz3sea8VeGRwlKErEZGn9rzbQCkrw0+8zhMi+QoEGOg UNKKiapk3APdcjdCf4nhBkL//K1GkRvnLeVlKKsZRtx+Gl+/TYPiAV0qOS1PTn/L9Rlr 8Ycht/H9zj4oo13MlhUosILb01iwl/AvDy8Ky6BTNdATt1NKRvi0ry5xLHPlf9uYH/KD Adile1Fe3XDzzd2JiidgCwuUmiV8TTsktjsaucEKG4eSEQQyj6ygngxs0ZlBe/+4xuXe XbXRWuvzc9kvj0XD+0J6w9UIOtGhN6mBO6f8mJ5U4xWFzKeUv8q4i49zwRtVHTfXb9xs YpZQ== MIME-Version: 1.0 References: <78e1f522-f6f5-d38d-0644-d083c1e4ab5d@redhat.com> In-Reply-To: <78e1f522-f6f5-d38d-0644-d083c1e4ab5d@redhat.com> From: David Griffiths Date: Thu, 21 Feb 2019 15:55:00 -0000 Message-ID: Subject: Re: "finish" command leads to SIGTRAP To: Pedro Alves Cc: gdb@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00044.txt.bz2 It's something to do with the nature of single stepping through a "popfq" instruction. Given the following instructions: 0x7fffe104638f: add $0x8,%rsp 0x7fffe1046393: popfq 0x7fffe1046394: pop %rbp 0x7fffe1046395: jmpq *%rax If I set a breakpoint at the first of that set and single step through, I end up with: eflags 0x346 [ PF ZF TF IF ] but if I set a breakpoint on the last instruction and avoid single stepping I get: eflags 0x246 [ PF ZF IF ] and I think it's that TF that is causing the SIGTRAP? On Thu, 21 Feb 2019 at 13:12, Pedro Alves wrote: > Might be unrelated, but ISTR that there used to be a kernel bug > that would lead to the cpu's trace flag getting stuck set > when you step in a signal handler. That would result in > SIGTRAP happening at every step from that point on. Could > that be the case here? > > I'd look at "set debug displaced on" too. Otherwise, it's a matter > at staring at the logs, and trying to understand what is happening. > Basically, "finish" sets a breakpoint at the caller and runs to it. > But all sorts of other things can happen behind the scenes. > > Thanks, > Pedro Alves > -- David Griffiths, Senior Software Engineer Undo | Resolve even the most challenging software defects with software flight recorder technology Software reliability report: optimizing the software supplier and customer relationship