Re: [PATCH RFA/RFC] Don't use lwp_from_thread() in thread_db_wait()

[Kevin Buettner <kevinb@redhat.com>]

On Mar 11,  9:47pm, Daniel Jacobowitz wrote:

> On Mon, Mar 11, 2002 at 04:45:54PM -0700, Kevin Buettner wrote:
> > I'm seeing the following failure when I run the gdb testsuite on an
> > SMP machine (GNU/Linux/x86):
> > 
> > FAIL: gdb.threads/pthreads.exp: continue to bkpt at common_routine in thread 2
> 
> Thank you for investigating this!  I've been seeing it somewhat
> erratically for months, but not had any idea where to start.
> 
> > thread_db_wait() wants to learn the lwp id of the thread that it
> > should wait for so that it can ask the lwp layer to wait on the lwp
> > corresponding to the thread in question.  In order to do this, it
> > calls lwp_from_thread().  lwp_from_thread needs help from the
> > libthread_db.so to figure this out, so it calls td_ta_map_id2thr(). 
> > BUT, this libthread_db function must interrogate the inferior
> > process's memory to look at the thread data structures.  To do this,
> > it calls back into gdb, using ps_pdread() to fetch the memory in
> > question.  Eventually, on Linux, ptrace() gets called to actually
> > fetch the memory.
> 
> There's another solution that I see.  At the top of thread-db is the
> comment:
> 
> /* FIXME: There is certainly some room for improvements:
>    - Cache LWP ids.
> 
> This would be a tremendous performance win, and fix this problem.  But
> that may be a slightly longer term solution.

I think that an LWP id cache is only useful so long as all of the
threads are stopped.  This is because the mappings could change in the
course of running the program.  So, for this particular case, where
the threads are running and we want to wait for one of them to stop,
the cache wouldn't be useful to us.

Of course, if we have knowledge that a particular thread
implementation never changes its mappings or perhaps only changes its
mappings for certain threads, we might be able to use such a cache
across the stop/start transitions.  However, I think that Mark had
intended for thread-db.c to be a fairly generic solution that's not
wedded to any one particular thread implementation.  In particular, it
should be possible to use it with an M:N model in which a thread may
migrate from one LWP to another.

That said, the LWP<->TID mapping operations are farily expensive
(since they involve fairly sizable target memory reads), and I agree
that an LWP cache would be beneficial even if it needs to be
invalidated when the program starts again.

Kevin