From: Pedro Alves <palves@redhat.com>
To: Yao Qi <yao@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH 4/7] range stepping: gdb
Date: Tue, 14 May 2013 18:31:00 -0000 [thread overview]
Message-ID: <51928303.3050407@redhat.com> (raw)
In-Reply-To: <1363006291-13334-5-git-send-email-yao@codesourcery.com>
On 03/11/2013 12:51 PM, Yao Qi wrote:
> @@ -4689,7 +4694,36 @@ append_resumption (char *p, char *endp,
> if (step && siggnal != GDB_SIGNAL_0)
> p += xsnprintf (p, endp - p, ";S%02x", siggnal);
> else if (step)
> - p += xsnprintf (p, endp - p, ";s");
> + {
> + struct thread_info *tp = NULL;
> + CORE_ADDR pc;
> +
> + gdb_assert (!ptid_equal (ptid, minus_one_ptid));
I think you'll trip on this in case the target supports
vCont but not actually listing thread ids (magic_null_ptid).
> +
> + if (ptid_is_pid (ptid))
> + tp = find_thread_ptid (inferior_ptid);
> + else
> + tp = find_thread_ptid (ptid);
> + gdb_assert (tp != NULL);
> +
> + pc = regcache_read_pc (get_thread_regcache (ptid));
> + if (rs->support_vCont.r /* Target supports step range. */
> + /* Can't do range stepping for all threads of a process
> + 'pPID.-1'. */
> + && !(remote_multi_process_p (rs) && ptid_is_pid (ptid))
> + /* Not step over a breakpoint. */
> + && !tp->control.trap_expected
> + /* We have a range to single step. */
> + && THREAD_WITHIN_SINGLE_STEP_RANGE (tp, pc))
This is problematic. It's better to _not_ have target itself decide
when to range step or to single step, and peeking at "infrun-owned"
variables. For example, with software watchpoints, GDB needs to have control
of single-steps, in order to evaluate the watchpoints at after each
instruction is executed, so trap_expected isn't enough. (My v3 adds a test for
that, that v2 fails.)
I dislike the design of using PC checks here too :-/. That
seems fragile, and potentially inefficient (considering GDB ever
sending more than one range action per packet, that might end up
fetching registers for threads unnecessarily). IMO, it's better to have
the core run control (infrun.c/infcmd.c) decide when to range step or
single-step.
> + {
> + p += xsnprintf (p, endp - p, ";r");
> + p += hexnumstr (p, tp->control.step_range_start);
> + p += xsnprintf (p, endp - p, ",");
> + p += hexnumstr (p, tp->control.step_range_end);
> + }
> + else
> + p += xsnprintf (p, endp - p, ";s");
> + }
> else if (siggnal != GDB_SIGNAL_0)
> p += xsnprintf (p, endp - p, ";C%02x", siggnal);
> else
>
Thanks,
--
Pedro Alves
next prev parent reply other threads:[~2013-05-14 18:31 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-11 12:52 [PATCH 0/7] Range stepping Yao Qi
2013-03-11 12:53 ` [PATCH 3/7] range stepping: gdbserver on x86/linux Yao Qi
2013-05-14 18:30 ` Pedro Alves
2013-05-15 7:40 ` Yao Qi
2013-05-20 18:00 ` Pedro Alves
2013-05-22 10:06 ` Yao Qi
2013-03-11 12:53 ` [PATCH 7/7] range stepping: doc and NEWS Yao Qi
2013-03-11 13:38 ` Abid, Hafiz
2013-03-11 17:01 ` Eli Zaretskii
2013-05-14 18:32 ` Pedro Alves
2013-03-11 12:53 ` [PATCH 2/7] Move rs->support_vCont_t to a separate struct Yao Qi
2013-03-11 12:53 ` [PATCH 1/7] New macro THREAD_WITHIN_SINGLE_STEP_RANGE Yao Qi
2013-05-14 19:24 ` Pedro Alves
2013-03-11 12:53 ` [PATCH 5/7] range stepping: New command 'maint set range stepping' Yao Qi
2013-03-11 17:05 ` Eli Zaretskii
2013-03-18 3:10 ` Yao Qi
2013-03-18 5:39 ` Eli Zaretskii
2013-05-14 18:31 ` Pedro Alves
2013-03-11 12:53 ` [PATCH 6/7] range stepping: test case Yao Qi
2013-05-14 18:32 ` Pedro Alves
2013-05-15 8:27 ` Yao Qi
2013-05-20 18:29 ` Pedro Alves
2013-05-22 14:01 ` Yao Qi
2013-03-11 12:53 ` [PATCH 4/7] range stepping: gdb Yao Qi
2013-05-14 18:31 ` Pedro Alves [this message]
2013-05-15 8:07 ` Yao Qi
2013-05-20 17:59 ` Pedro Alves
2013-03-14 20:12 ` [PATCH 0/7] Range stepping Pedro Alves
2013-03-15 19:54 ` Pedro Alves
2013-03-22 2:25 ` Yao Qi
2013-03-22 20:24 ` Pedro Alves
2013-04-11 6:16 ` [PATCH 0/7 V2] " Yao Qi
2013-04-11 6:17 ` [PATCH 1/7] New macro THREAD_WITHIN_SINGLE_STEP_RANGE Yao Qi
2013-04-11 6:17 ` [PATCH 2/7] Move rs->support_vCont_t to a separate struct Yao Qi
2013-04-11 6:18 ` [PATCH 3/7] range stepping: gdbserver on x86/linux Yao Qi
2013-04-11 6:19 ` [PATCH 4/7] range stepping: gdb Yao Qi
2013-04-11 13:22 ` Yao Qi
2013-04-12 12:35 ` Yao Qi
2013-04-11 6:19 ` [PATCH 5/7] range stepping: New command 'maint set range stepping' Yao Qi
2013-04-11 23:00 ` Eli Zaretskii
2013-04-11 6:38 ` [PATCH 6/7] range stepping: test case Yao Qi
2013-04-11 7:30 ` [PATCH 7/7] range stepping: doc and NEWS Yao Qi
2013-04-11 23:00 ` Eli Zaretskii
2013-04-12 20:48 ` [PATCH 0/7 V2] Range stepping 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=51928303.3050407@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=yao@codesourcery.com \
/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