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

[Daniel Jacobowitz <drow@mvista.com>]

On Tue, Mar 12, 2002 at 12:52:16AM -0700, Kevin Buettner wrote:
> On Mar 11, 10:23pm, Daniel Jacobowitz wrote:
> 
> > On Mon, Mar 11, 2002 at 08:16:19PM -0700, Kevin Buettner wrote:
> > > 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.
> > 
> > This implies that part of the caching should be in lin-lwp.c rather
> > than in thread-db.c... that knowledge belongs with the lower level
> > threading layer.  Does that make sense?
> 
> I think I see what you're driving at, though I don't think it belongs
> in lin-lwp.c.  lin-lwp.c should, I hope, be usable as is by a number
> of different thread implementations.  Instead, I think what you have
> in mind should reside in some sort of policy adjuct to thread-db.c
> which understands the kinds of relationships that can exist between
> thread ids and lwp ids.  If it knows that the thread implementation
> uses a 1:1 model as linuxthreads does now, it can use agressive
> caching.  (By which I mean that the cache is allowed to persist
> between stops in the debugger).  If it uses a M:N model, it must cache
> more conservatively.  (I.e, the cache must be invalidated whenever the
> inferior is resumed.)  I think this code could be reasonably generic
> and it shouldn't be too hard to implement.  The difficult part will be

I like this a lot.

> to figure out which kind of thread library you have.  After all, if
> someone provided a dropin replacement for linuxthreads which
> implemented M:N threading, how would you tell the difference?

... great care, and maybe a ``set'' option to override?  Unfortunately,
IBM's ngpt seems to be mostly drop-in, barring some symbol versioning
complexity.  We can probably find a way to distinguish...  what's worse
is that NGPT can build as a libpthread.so, but not a libthread_db.so,
so we may have to handle mismatches :(

> > We could also, for instance, update the cache via thread event
> > reporting...
> 
> If the thread events tell GDB when a thread has migrated from one
> LWP to another, then this would work too.

Yes, that could probably be arranged.  Someday we should talk to a
vendor of an M:N threads package and see what we have to work with.  I
don't know of any offhand besides NGPT.

> ...
> 
> But, for the problem at hand (i.e, the bug that my patch is intended
> to fix), I think it's important that we first make it work without
> caching.  As I see it, the cache ought to exist to enhance
> performance, not guarantee basic correctness.  If we can't make it
> work without some sort of caching or enhanced thread event reporting,
> we need to understand exactly why first.

I agree.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer