This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 3/7] range stepping: gdbserver on x86/linux


On 05/15/2013 08:40 AM, Yao Qi wrote:
> On 05/15/2013 02:30 AM, Pedro Alves wrote:
>>   - it assumes GDB will ever only send one r action per vCont.  I'd much
>>     rather we don't bake in that assumption.
>>
> 
> I am afraid not.  It works for multiple r actions in one vCont.

Oh, sorry about that.  :-/  That wasn't actually the issue I had noticed
initially, and then when I went back to compose the email, I had
already forgotten and got it mixed up.  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
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).

-- 
Pedro Alves


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]