This is the mail archive of the gdb@sources.redhat.com 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: RFC: Two small remote protocol extensions



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.).

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 :-?

Andrew



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