From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41928 invoked by alias); 21 Feb 2019 17:50:56 -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 41914 invoked by uid 89); 21 Feb 2019 17:50:56 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=stepped, posting X-HELO: mail-wm1-f67.google.com Received: from mail-wm1-f67.google.com (HELO mail-wm1-f67.google.com) (209.85.128.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Feb 2019 17:50:54 +0000 Received: by mail-wm1-f67.google.com with SMTP id q187so10464018wme.5 for ; Thu, 21 Feb 2019 09:50:54 -0800 (PST) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:75e6:857f:3506:a1f4? ([2001:8a0:f913:f700:75e6:857f:3506:a1f4]) by smtp.gmail.com with ESMTPSA id h17sm17925186wrq.17.2019.02.21.09.50.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 21 Feb 2019 09:50:51 -0800 (PST) Subject: Re: "finish" command leads to SIGTRAP To: David Griffiths References: <78e1f522-f6f5-d38d-0644-d083c1e4ab5d@redhat.com> Cc: gdb@sourceware.org From: Pedro Alves Message-ID: <743edbbc-9812-c8e7-0f47-7b4842199b48@redhat.com> Date: Thu, 21 Feb 2019 17:50:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-02/txt/msg00047.txt.bz2 On 02/21/2019 03:54 PM, David Griffiths wrote: > It's something to do with the nature of single stepping through a "popfq" > instruction. Given the following instructions: I assume you have a pushf somewhere earlier? > > 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? Same as ? I can reproduce that here, on Fedora 27 / Linux 4.17.17-100.fc27.x86_64. Sounds like PTRACE_SINGLESTEP enables TF, which then causes pushf to push the state with TF set. And then popf pops restores that TF-enabled state. I'd think this is a kernel bug, in the same vein as the signal issue I mentioned below (in which TF would get stuck when you stepped into a signal handler, or something like that). The kernel could have special handling for pushf, emulating it instead of actually single-stepping it? Maybe newer Linux kernels do something else. Haven't tried. I wonder what other kernels, like e.g., FreeBSD do here? Guess if GDB is to workaround this, it'll have to either add special treatment for this instruction (emulate, step over with a software breakpoints, something like that), or clear TF manually after single-stepping. :-/ Thanks, Pedro Alves (please avoid top posting) > > > 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. >>