Re: [rfc] Preferred thread event reporting: Linux native target

[Pedro Alves <pedro@codesourcery.com>]

On Thursday 14 August 2008 22:50:22, Ulrich Weigand wrote:
> Pedro Alves wrote:
> > > -- this is actually simply the currently selected thread
> > > (i.e. the current value of inferior_ptid).
> >
> > Disagreed.  inferior_ptid will change if an event happens in
> > another thread while you're stepping, but the core decides the event
> > was not a good reason to stop.  E.g., thread hopping.
>
> Hmm, but if we "thread hop" inferior_ptid should be prefered
> anyway (to get the internal "thread hop" action over with as
> quickly as possible), 

When we thread hop, we tell the target to only allow a single
thread to run.  On linux, there's no way to could already have a
cached event in the thread the user is stepping at
this point, otherwise, we'd not have detected the need for a
thread hop.  So, right after resuming to do the thread hop, if
there's any other cached event to select from, because
they were cached when we reported the stop that originated
the thread hop, it won't be from the thread the user was
stepping.

But, this above is moot currently, because when we
thread hop, we enter infwait_thread_hop_state, which
ends up forcing linux_nat_wait to only return with the ptid of
the thread we're hopping, thus, the thread hop action gets over
as quickly as possible already.

> and afterwards we're back to the thread 
> the user is looking at, right?

Well, in all-stop, there's nothing doing that currently.  when
you switch inferior_ptid (in all-stop mode) to handle a
possible stop, and then you decide you should not stop, there's
nothing reverting back to the previous thread.  inferior_ptid will
stay pointing to the last thread you resumed (the hopping thread),
until you hit another stop event, and context_switch to the thread
that took it.

> > For my series to go in, every target much register at least the main
> > thread in GDB's thread tables, and as it happens, I think AIX
> > is the only target I don't have covered, or that I know of
> > no one covering.
>
> I can test AIX if necessary.  Do you have a patch?

I stratched my head quite a bit staring at aix-thread.c/sync_threadlists
and its use of ptid_cmp.  I still can't tell if/what I should do there.
Also, I can't tell if rs6000_wait can ever return a ptid
different from pid_to_ptid(main_process_pid), (or -1).

Basically, I need to:

 1) make sure the core never gets a thread related event
    that corresponds to a thread the core doesn't know
    about yet.

 2) #1 implies that every target should register the main
   thread, even when debugging a single-threaded app.
   rs6000-nat.c, being a ptrace based target, already has that
   covered by these:
    http://sourceware.org/ml/gdb-patches/2008-08/msg00170.html
    http://sourceware.org/ml/gdb-patches/2008-08/msg00171.html

 3) #2 implies that a thread_stratum layer should decorate the
    main thread's ptid with thread id info, instead of adding it
    again. That's thread_change_ptid from:    
    http://sourceware.org/ml/gdb-patches/2008-08/msg00170.html

-- 
Pedro Alves