This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH RFA/RFC] Don't use lwp_from_thread() in thread_db_wait()
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