From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126178 invoked by alias); 22 Feb 2019 16:42:41 -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 126116 invoked by uid 89); 22 Feb 2019 16:42:40 -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=reproduced, fine-grained, finegrained 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; Fri, 22 Feb 2019 16:42:38 +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 79E2E92D32; Fri, 22 Feb 2019 16:42:36 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 8CEE275028; Fri, 22 Feb 2019 16:42:35 +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 D111815DB5; Fri, 22 Feb 2019 16:42:34 +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> <863e96ac-83c4-feb3-e412-95b647d18201@FreeBSD.org> <9e24e676-ff37-bf4b-3fd0-a9fda0798abb@redhat.com> <6c1aae34-5bce-a524-11d6-0e12b53b9ac2@FreeBSD.org> <257d6eda-21b5-970f-0fe4-f96fefe56a44@redhat.com> From: John Baldwin Openpgp: preference=signencrypt Message-ID: <8ad15d6e-07be-d175-6345-dddfb46f1b58@FreeBSD.org> Date: Fri, 22 Feb 2019 16:42: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: <257d6eda-21b5-970f-0fe4-f96fefe56a44@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 8CEE275028 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-2.94 / 15.00]; local_wl_from(0.00)[FreeBSD.org]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; NEURAL_HAM_SHORT(-0.94)[-0.937,0]; ASN(0.00)[asn:11403, ipnet:96.47.64.0/20, country:US]; NEURAL_HAM_LONG(-1.00)[-0.999,0] X-IsSubscribed: yes X-SW-Source: 2019-02/txt/msg00059.txt.bz2 On 2/22/19 7:09 AM, Pedro Alves wrote: > On 02/21/2019 08:49 PM, John Baldwin wrote: >> On 2/21/19 11:34 AM, Pedro Alves wrote: >>> #3 - have gdb always clear TF after a single-step. This is the >>> easiest, even if the "less technically cool" solution. This >>> would mean that it'd be impossible to debug a program that >>> sets the trace flag manually. I've actually once co-wrote >>> an in-process x86 debug stub, and in that use case >>> preserving TF mattered, made it possible to debug that >>> stub... Quite a niche use case, though, and it'd have been >>> trivial for me for hack gdb for that special use case, of course. >>> >>> In order for GDB to know whether it is stepping a pushf instruction, >>> it needs to read the memory at PC, which has a cost, but maybe it's >>> negligible if we already end up reading memory anyway (because of the >>> code cache), but I'm not sure we already do. This can have a more >>> noticeable effect with remote debugging (which should weigh on whether >>> to do the workaround at the infrun.c level, or in the target backend (thus >>> in gdbserver when remote). >>> >>> Solution #3 would require extra ptrace commands anyway (read-modify-write >>> the flags), so it may end up being less performant, if #1 and #2 already >>> hit the code cache. >>> >>> There are some extra complications around #1 and #2 for gdbserver, >>> because we need to consider the cases when gdbserver handles >>> single-stepping without roundtripping to gdb: >>> >>> - range-stepping >>> - stepping over breakpoints/tracepoints >> >> Hmmm, I will probably try to fix (or get someone else to fix) FreeBSD's >> kernel regardless probably using the approach in #1. For GDB itself, I >> probably have a slight preference for #2 over #1, but I haven't yet worked >> with gdbserver, so I'd defer to you on if #3 is the best solution when >> taking gdbserver into account. If the edge case of #3 matters, (which might >> matter for some other things like some language runtimes that set TF and use >> SIGTRAP handlers that motivated FreeBSD's kernel changes last year), we >> could perhaps provide a way for targets to override #3 if they know they >> don't need it (e.g. a native target under a kernel known to work). Not >> sure how that would work over remote (e.g. if you would want gdbserver to >> internalize this behavior so that only it deals with it and hides it from >> the remote debugger). > > I'd prefer #1 or #2 over #3. As for gdbserver, the thing is that whatever > solution we implement in gdb isn't going to fix gdbserver, gdbserver > needs fixing as well. gdbserver has its own run control loop that does > single-stepping behind gdb's back. The most common case nowadays is > range-stepping. When you do "next", or "step", as an optimization, gdb > tells gdbserver to single-step as long the PC is within an address range > (the continuous address range that corresponds to the current line > that includes PC). gdbserver then continually single-steps, and only > reports back a stop to GDB once the PC leaves the range. This avoids > many roundtrips between gdb and gdbserver. This means that gdbserver > must have some workaround too. For this case alone, we could just > make gdbserver punt and report a stop to gdb if the next instruction is > a pushf (gdb continues stepping itself, which would trigger the workaround). > BUT, that wouldn't address the less frequent case -- tracepoints: > gdbserver needs to step over them without gdb involvement, and needs to > implement while-stepping actions. So here we can't punt to gdb, there > may not even be one connected! So we need to a full workaround > in gdbserver. I thought of one more issue with #3 which is that it's not necessarily that you need to clear TF after each step. The way I reproduced this when I ran the test program was to si over the pushf, then do a continue. This meant that we weren't stepping when the popf was executed, and the instruction after popf then raised a spurious SIGTRAP. At that point, the thread's current state isn't stepping. One way perhaps to handle this was if you could specifically determine that a SIGTRAP was a step and if the you get an unexpected step trap, resume the thread anyway (possibly clearing TF as part of the resume). This wouldn't be hard to do in individual native targets where you have the siginfo for the SIGTRAP. It's harder to do at a higher layer I think. One thing I've wondered about when adding the siginfo parsing for the FreeBSD native target is that it feels like it would be nicer if a target could return more fine-grained waitkinds, something like TARGET_WAITKIND_STEPPED, TARGET_WAITKIND_SW_BREAKPOINT, etc. instead of requiring the various methods like 'supports_stopped_by_sw_breakpoint' and 'stopped_by_sw_breakpoint' and assuming that SIGTRAP is a step if the current thread is stepping and none of the other 'stopped_by_foo' methods return true. You could maybe still have a fallback for TARGET_WAITKIND_STOPPED that would use the same heuristics for targets that don't parse siginfo to infer the more detailed stop type perhaps? Having that detail at a higher level would make it easier to recognize spurious step traps in the core I think. That's probably too big a change just to workaround this issue, but still a thought I've had for a while. -- John Baldwin                                                                            Â