Re: [RFC] 07/10 non-stop inferior control

[Pedro Alves <pedro@codesourcery.com>]

A Friday 09 May 2008 02:44:54, Daniel Jacobowitz wrote:
> On Fri, May 09, 2008 at 02:22:51AM +0100, Pedro Alves wrote:
> > Isn't this new_thread_event handling a bandaid for some
> > misbehaving target?  My understanding was that targets should handle
> > new thread events (and call add_thread*) themselves nowadays.
>
> That might be a little strong; but the Linux and remote targets do so,
> because it was much more convenient.
>

Ok.  If you know off-hand of any target that relies on
new_thread_event, I'd like to get to know it.  I think it's very bad
to rely on core GDB to do add threads.  context_switch needed to be
bandaided for cases where threads are not managed by the target.  We
can't distinguish a case of the target escaping a bad ptid_t due
to a bug from a valid event.

The comments around this aren't too optimistic.

static void
context_switch (ptid_t ptid)
{
  /* Caution: it may happen that the new thread (or the old one!)
     is not in the thread list.  In this case we must not attempt
     to "switch context", or we run the risk that our context may
     be lost.  This may happen as a result of the target module
     mishandling thread creation.  */

static void
record_currthread (int currthread)
{
  general_thread = currthread;

  /* If this is a new thread, add it to GDB's thread list.
     If we leave it up to WFI to do this, bad things will happen.  */
  if (!in_thread_list (pid_to_ptid (currthread)))
    add_thread (pid_to_ptid (currthread));

The only benefit of letting the core handle new threads, would
be to add support to stop on new thread events.  But, this form
is of questinable value.  I would argue for implementing that
with events/catchpoints, and/or a new target_waitstatus.

> > Since this is a new mode that will require adaptation
> > by each target, it sounded reasonable to require that the
> > the new_thread_event should never be hit, and that the
> > target handles adding threads to GDB's thread list.
>
> If documented in gdbint, I think this would be a reasonable new
> restriction.

Ok.  I haven't managed to get to the docs yet, but I'll get
to it.

-- 
Pedro Alves