On Monday 11 January 2010 17:17:16 Pedro Alves wrote:

> > - Introduce thread_get_core function in thread.c. That thread will
> >   be documented as returning the core a given thread was last noticed
> >   running on by GDB, with that information updated either by
> >   update_thread_list or when a thread stops. We'd need a new field
> >   inside thread_info to keep this information.
> > - Make linux native update core information for all threads when
> >   listing them.
> 
> Sounds good to me.  Note that linux-nat.c doesn't list threads,
> linux-thread-db.c does.
> 
> > What I am primarily trying to avoid is introducing a packet to get
> > core information for a single running thread. That will be slow,
> > and such functionality is not required by anything at present.
> 
> That's fine.  My gripe is in the disconnect between the
> documentation of what the method should do, and what it
> actually does.

Here's the patch revised per above, and offlist discussion. For the benefit
of list, the problem with the above scheme is that linux_nat_wait seems
like the best place to record core, however, a new thread is only added to
the thread list by linux_thread_db_wait, and while in practice, a thread
will always stop on thread breakpoint and before stopping for real, and
therefore will be present in the thread table when linux_nat_wait wishes
to record core number, such design is brittle. So, this revision makes
linux native behave similarly to remote, and adjust documentation on
the to_core_of_thread method to match that behaviour.

This patch also fixes a few formatting issues that whitespace-mode found,
and adjust naming of some functions to be consistent.



- Volodya