This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcore and nptl threads on linux


On Wed, Mar 05, 2003 at 07:56:01PM -0500, Andrew Cagney wrote:
> 
> >>I would think the null_ptid would serve in such a case.
> >
> >
> >I guess the issue is that we should be dumping the set of LWPs to the
> >generated core file, not the set of threads.  It seems to me like GDB
> >should be aware of the list of LWPs, and it shouldn't be hidden in each
> >individual thread package.
> 
> You mean add them to the `struct thread_info' list?  Why not (ignoring 
> technical realities for the moment :-)?

Well, I wouldn't do it that way.  I haven't really designed this, so
bear with me if it has some squishy spots.

I think there should be two lists:
  all threads
  all lwps

Should the data structures be the same?  I don't know.  The mapping
between them would be defined by the thread stratum; its role would be
to take thread requests, convert them to LWP requests, and pass them
on.  The process stratum would be responsible for managing all of the
LWPs.

This has some advantages, I think.  Here's one: we would have a logical
interface for reporting an event from an LWP that doesn't currently
have a thread.  This happens in LinuxThreads, as I've mentioned
recently.  The thread stratum could see that the inferior ptid was just
an LWP id and pass the request along no questions asked.

Hmm, definitely some loose edges in that one.  Should both an LWP and a
thread have a regcache?  Might work.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]