From: Pedro Alves <palves@redhat.com>
To: Doug Evans <dje@google.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v3 07/17] Misc switch_back_to_stepped_thread cleanups
Date: Wed, 22 Apr 2015 20:05:00 -0000 [thread overview]
Message-ID: <5537FEF1.7000100@redhat.com> (raw)
In-Reply-To: <21815.12255.713123.668054@ruffy2.mtv.corp.google.com>
On 04/22/2015 06:21 AM, Doug Evans wrote:
> Pedro Alves writes:
> > [...] it isn't ever correct to pass step=1 to target_resume
> > on software single-step targets [...]
>
> Sounds like a good thing to document in a comment or assert.
Yeah, we were discussing adding an assertion on the gdbserver
side here:
https://sourceware.org/ml/gdb-patches/2015-04/msg00232.html
An assertion on the gdb side is complicated, and I'd rather that be
done separately. gdbarch_software_single_step_p() returning true
does not mean that we can't use hardware step. E.g., ppc installs
that hook for stepping past atomic regions. We can't assert based on
software single-step breakpoints inserted, as infrun.c uses those
even on targets that don't implement gdbarch_software_single_step_p.
We could add a new target_can_hardware_single_step method, which
ideally for remote targets would be based on the reply to the "vCont?"
probe packet, but gdbserver always includes "s" actions in the reply
even on targets that can't hardware step, and we can't just make it
not do that, since remote.c:remote_vcont_probe has:
/* If s, S, c, and C are not all supported, we can't use vCont. Clearing
BUF will make packet_ok disable the packet. */
if (!support_s || !support_S || !support_c || !support_C)
buf[0] = 0;
so even if we fixed mainline, newer gdbserver against older gdb
would be broken... So we need something else or in addition (probably
based on qSupported).
For comments, how about this?
diff --git i/gdb/infrun.c w/gdb/infrun.c
index 0bf1274..fbe12ab 100644
--- i/gdb/infrun.c
+++ w/gdb/infrun.c
@@ -5839,7 +5839,9 @@ switch_back_to_stepped_thread (struct execution_control_state *ecs)
return 0;
}
-/* Is thread TP in the middle of single-stepping? */
+/* Is thread TP in the middle of (software or hardware)
+ single-stepping? (Note the result of this function must never be
+ passed directly as target_resume's STEP parameter.) */
static int
currently_stepping (struct thread_info *tp)
diff --git i/gdb/target.h w/gdb/target.h
index 66bf91e..283f56f 100644
--- i/gdb/target.h
+++ w/gdb/target.h
@@ -1254,8 +1254,8 @@ extern void target_detach (const char *, int);
extern void target_disconnect (const char *, int);
/* Resume execution of the target process PTID (or a group of
- threads). STEP says whether to single-step or to run free; SIGGNAL
- is the signal to be given to the target, or GDB_SIGNAL_0 for no
+ threads). STEP says whether to hardware single-step or to run free;
+ SIGGNAL is the signal to be given to the target, or GDB_SIGNAL_0 for no
signal. The caller may not pass GDB_SIGNAL_DEFAULT. A specific
PTID means `step/resume only this process id'. A wildcard PTID
(all threads, or all threads of process) means `step/resume
Thanks,
Pedro Alves
next prev parent reply other threads:[~2015-04-22 20:05 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-04-17 10:47 [PATCH v3 00/23] All-stop on top of non-stop Pedro Alves
2015-04-17 10:45 ` [PATCH v3 05/17] Embed the pending step-over chain in thread_info objects Pedro Alves
2015-04-21 8:28 ` Yao Qi
2015-04-22 20:14 ` Pedro Alves
2015-04-21 9:53 ` Yao Qi
2015-04-22 19:07 ` Pedro Alves
2015-04-22 4:25 ` Doug Evans
2015-04-22 22:19 ` Pedro Alves
2015-04-17 10:45 ` [PATCH v3 02/17] Change adjust_pc_after_break's prototype Pedro Alves
2015-04-17 10:45 ` [PATCH v3 11/17] Fix signal-while-stepping-over-bp-other-thread.exp on targets always in non-stop Pedro Alves
2015-04-17 10:45 ` [PATCH v3 04/17] Make thread_still_needs_step_over consider stepping_over_watchpoint too Pedro Alves
2015-04-17 10:45 ` [PATCH v3 15/17] PPC64: Fix gdb.arch/ppc64-atomic-inst.exp with displaced stepping Pedro Alves
2015-04-21 11:21 ` Yao Qi
2015-04-22 20:04 ` Pedro Alves
2015-04-17 10:45 ` [PATCH v3 08/17] Factor out code to re-resume stepped thread Pedro Alves
2015-04-17 10:45 ` [PATCH v3 03/17] remote.c/all-stop: Implement TARGET_WAITKIND_NO_RESUMED and TARGET_WNOHANG Pedro Alves
2015-04-17 10:45 ` [PATCH v3 13/17] Fix step-over-{trips-on-watchpoint|lands-on-breakpoint}.exp race Pedro Alves
2015-04-17 10:45 ` [PATCH v3 06/17] Use keep_going in proceed and start_step_over too Pedro Alves
2015-04-22 5:09 ` Doug Evans
2015-04-22 22:22 ` Pedro Alves
2015-04-17 10:47 ` [PATCH v3 01/17] Fix and test "checkpoint" in non-stop mode Pedro Alves
2015-04-21 2:36 ` Doug Evans
2015-04-22 17:48 ` Pedro Alves
2015-04-28 18:18 ` Doug Evans
2015-04-29 4:56 ` Doug Evans
2015-05-19 18:08 ` Pedro Alves
2015-04-17 10:47 ` [PATCH v3 07/17] Misc switch_back_to_stepped_thread cleanups Pedro Alves
2015-04-21 9:50 ` Yao Qi
2015-04-22 20:04 ` Pedro Alves
2015-04-22 5:23 ` Doug Evans
2015-04-22 20:05 ` Pedro Alves [this message]
2015-04-28 20:28 ` Doug Evans
2015-04-17 10:47 ` [PATCH v3 17/17] native Linux: enable always non-stop by default Pedro Alves
2015-04-17 10:52 ` [PATCH v3 09/17] Teach non-stop to do in-line step-overs (stop all, step, restart) Pedro Alves
2015-04-17 11:01 ` Pedro Alves
2015-04-21 15:01 ` Yao Qi
2015-04-22 20:03 ` Pedro Alves
2015-04-24 9:06 ` Yao Qi
2015-04-27 20:17 ` Doug Evans
2015-05-19 18:09 ` Pedro Alves
2015-05-19 18:49 ` Pedro Alves
2015-04-17 10:52 ` [PATCH v3 12/17] Fix interrupt-noterm.exp on targets always in non-stop Pedro Alves
2015-04-21 11:40 ` Yao Qi
2015-04-22 20:03 ` Pedro Alves
2015-04-17 10:56 ` [PATCH v3 14/17] Disable displaced stepping if trying it fails Pedro Alves
2015-04-17 11:06 ` [PATCH v3 16/17] S/390: displaced stepping and PC-relative RIL-b/RIL-c instructions Pedro Alves
2015-04-17 11:38 ` [PATCH v3 10/17] Implement all-stop on top of a target running non-stop mode Pedro Alves
2015-04-21 11:09 ` Yao Qi
2015-04-22 20:16 ` Pedro Alves
2015-04-24 7:39 ` Yao Qi
2015-05-19 18:08 ` Pedro Alves
2015-05-21 9:17 ` Yao Qi
2015-04-20 12:02 ` [PATCH v3 00/23] All-stop on top of non-stop Yao Qi
2015-04-20 16:54 ` Sergio Durigan Junior
[not found] ` <553526D0.9030802@redhat.com>
2015-04-21 7:48 ` Yao Qi
2015-04-21 15:05 ` Yao Qi
2015-04-22 22:27 ` Pedro Alves
2015-04-20 17:35 ` Simon Marchi
2015-05-19 18:14 ` Pedro Alves
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5537FEF1.7000100@redhat.com \
--to=palves@redhat.com \
--cc=dje@google.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox