This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 3/7] range stepping: gdbserver on x86/linux
- From: Yao Qi <yao at codesourcery dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: <gdb-patches at sourceware dot org>
- Date: Wed, 22 May 2013 18:06:38 +0800
- Subject: Re: [PATCH 3/7] range stepping: gdbserver on x86/linux
- References: <1363006291-13334-1-git-send-email-yao at codesourcery dot com> <1363006291-13334-4-git-send-email-yao at codesourcery dot com> <519282CB dot 4030800 at redhat dot com> <51933C0B dot 1060109 at codesourcery dot com> <519A64BD dot 8030104 at redhat dot com>
On 05/21/2013 02:00 AM, Pedro Alves wrote:
The issue was actually with:
if (end > 0)
{
struct thread_info *tp = find_thread_ptid (ptid);
/* GDB should not send range stepping for all threads of
a process, like 'vCont;rSTART,END:pPID.-1', TP can't
be NULL. */
gdb_assert (tp != NULL);
I think it's best not to error on this as nothing in the protocol actually
prohibits it, and we might take advantage of it at some point. The way
OK, looks I abused gdb_assert some times, :).
gdbserver handles vCont requests currently is by letting the target
match the ptid to whatever thread/lwp. That means leaving server.c
only knowing about how to parse the rsp and construct a thread_resume,
and then pass that down to the target. Conceivably, a target might
not need to keep the step range anywhere, if it has something like
a PTRACE_STEP_RANGE at the kernel level. (There's PTRACE_BLOCKSTEP,
but it's not the same).
Yeah, that makes sense to me. I didn't realize such abstraction when
reading the code. Thanks for your explanation.
--
Yao (éå)