From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29487 invoked by alias); 21 Feb 2019 18:50:02 -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 29241 invoked by uid 89); 21 Feb 2019 18:49:59 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=boot, rework, H*r:Client, baldwin X-HELO: mx2.freebsd.org Received: from mx2.freebsd.org (HELO mx2.freebsd.org) (8.8.178.116) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 21 Feb 2019 18:49:57 +0000 Received: from mx1.freebsd.org (mx1.freebsd.org [96.47.72.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx2.freebsd.org (Postfix) with ESMTPS id 2BB4A93BBB; Thu, 21 Feb 2019 18:49:56 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6F6F9884AD; Thu, 21 Feb 2019 18:49:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from John-Baldwins-MacBook-Pro-3.local (ralph.baldwin.cx [66.234.199.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id C5574CE05; Thu, 21 Feb 2019 18:49:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Subject: Re: "finish" command leads to SIGTRAP To: Pedro Alves , David Griffiths Cc: gdb@sourceware.org References: <78e1f522-f6f5-d38d-0644-d083c1e4ab5d@redhat.com> <743edbbc-9812-c8e7-0f47-7b4842199b48@redhat.com> From: John Baldwin Openpgp: preference=signencrypt Message-ID: <863e96ac-83c4-feb3-e412-95b647d18201@FreeBSD.org> Date: Thu, 21 Feb 2019 18:50:00 -0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: <743edbbc-9812-c8e7-0f47-7b4842199b48@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 6F6F9884AD X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.95 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.95)[-0.948,0]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; ASN(0.00)[asn:11403, ipnet:2610:1c1:1::/48, country:US] X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00052.txt.bz2 On 2/21/19 9:50 AM, Pedro Alves wrote: > 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? FreeBSD also fails (and in the last year we had a set of changes to rework TF handling in the kernel to boot). This doesn't look trivial to solve. To get the exception you have to have TF set in %rflags/%eflags, but that means it is set when the pushf writes to the stack. I think what would have to happen (ugh) is that the kernel needs to recognize that the DB# fault is due to a pushf instruction and that if the TF was a "shadow" TF due to ptrace it needs to clear TF from the value written on the stack as part of the fault handler. > 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. :-/ I suspect it will be common for kernels to have this bug because the CPU will always write a value onto the stack with TF set as part of executing the instruction. A workaround in GDB would be much like what I described above with the advantage that GDB actually knows it is stepping a pushf before it steps it, so it can know to rewrite the value on the stack after it gets the SIGTRAP for the single step over the pushf. This may actually be hard for a kernel to get right as at the time of the fault we don't get anything that says how long the faulting instruction was, etc. Thus, just looking at the byte before the current eip/rip in a DB# fault handler for the pushf opcode (I believe it's a single byte) can get false positives because you might have stepped over a mov instruction with an immediate whose last byte happens to be the opcode, etc. -- John Baldwin                                                                            Â