Re: RFC: Two small remote protocol extensions

[Daniel Jacobowitz <drow at mvista dot com>]

On Fri, Aug 23, 2002 at 03:53:18PM -0400, Andrew Cagney wrote:
> 
> >Inferior_ptid is set in this case.  That's the whole problem; they have
> >access to it, but the remote implementation doesn't.  The code from
> >lin-lwp:
> >
> >  /* Apparently the interpretation of PID is dependent on STEP: If
> >     STEP is non-zero, a specific PID means `step only this process
> >     id'.  But if STEP is zero, then PID means `continue *all*
> >     processes, but give the signal only to this one'.  */
> >  resume_all = (PIDGET (ptid) == -1) || !step;
> >
> >  if (resume_all)
> >    iterate_over_lwps (resume_set_callback, NULL);
> >  else
> >    iterate_over_lwps (resume_clear_callback, NULL);
> >
> >  /* If PID is -1, it's the current inferior that should be
> >     handled specially.  */
> >  if (PIDGET (ptid) == -1)
> >    ptid = inferior_ptid;
> >
> >(I'm not quite sure about that comment; that might want to be revisited
> >later... there should be a way to continue just one process.  I thought
> >I remembered that working, but I must have been mistaken.)
> 
> Hmm,
> 
> I'm more interested in Solaris (since that target has a thread model 
> which allows control of the entire thread group).  With that one, I 
> couldn't find an equivalent operation (I've probably missed it.).

Let me see... sol_thread_resume:
  inferior_ptid = thread_to_lwp (inferior_ptid, PIDGET (main_ph.ptid));

procfs_resume:
  /* Find procinfo for main process */
  pi = find_procinfo_or_die (PIDGET (inferior_ptid), 0);

After that if PIDGET (ptid) == -1, it operates on the procinfo it got
from inferior_ptid.  Which is an LWP.  I'm not sure precisely that will
happen if you resume a specific LWP under Solaris; presumably it will
resume that LWP's "current" thread in some sense, I don't know if that
will behave predictably or not.  I'm not familiar with Solaris threads.

> It's just really wierd (wrong?) that one layer of GDB thinks that it 
> only needs to specify the step thread when doing the thread hop, yet the 
> next layer down finds it necessary to always specify the step thread :-?

Sure.  I suppose we should clean up the interface to resume, to prevent
all this confusion re-arising... which means figuring out our possible
behaviors, and whether they are even implementable on particular
targets.

On Linux the options for any given LWP (at the moment, that means for
any given thread) are step, run, stop.  All combinations are available. 
I think the _useful_ ones are:

  step one, stop others
  step one, continue others
  continue one, stop others
  continue one, continue others

And, of course:
  stop one, stop others
:)

Something like:
  resume (ptid, step, run_others, target_signal)
maybe?  Does anyone think step_all is useful (I don't)?


PS:
Some day letting the user be more precise (run these two threads) would
be nice.  I envision a day in the distant future:
 -> Continue thread 1
 -> Continue thread 2
 -> Wait for inferior status
 <- All threads stopped, thread 1, SIGSEGV
or
 -> Continue all threads
 -> Wait for inferior status [maybe implicit in the all-threads
				request]
 <- Thread 1 stopped, shared lib breakpoint, all other threads running

But let's not try to design to that quite yet :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer