Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <ac131313@redhat.com>
To: Daniel Jacobowitz <drow@mvista.com>
Cc: "J. Johnston" <jjohnstn@redhat.com>, gdb@sources.redhat.com
Subject: Re: gcore and nptl threads on linux
Date: Thu, 06 Mar 2003 01:44:00 -0000	[thread overview]
Message-ID: <3E66A811.8030203@redhat.com> (raw)
In-Reply-To: <20030306010428.GA17878@nevyn.them.org>

> 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

I believe in `zero, one, many':

- lwps
- processes
- threads (as in pthread)
- threads (as in a java interpreter thread)
- tasks (as in ada)

Each has something like:

- an architecture
- a target
- an owner?

For instance, an ada task might be implemented using a p-thread, which 
might in turn be implemented using an lwp-thread.  Only, the task is 
doing an rpc to java interpreter thread running in a separate process.

Each category can either maintain a local private database, or they can 
all share a common database.  If the info is more central, it becomes 
easier for the user to query/manipulate it.

> 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.

Things to do today should include throwing out stratum (along with the 
bath water).

> 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.

?  That sounds a bit up-side-down, shouldn't events be propogating up - 
lwp gets to see them before thread?

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

Don't forget that a regcache is just a local performance optimization - 
a look-a-side buffer.

Andrew



  reply	other threads:[~2003-03-06  1:44 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-03-04 23:40 J. Johnston
2003-03-05  0:52 ` Daniel Jacobowitz
2003-03-05 17:05   ` J. Johnston
2003-03-05 17:25     ` Daniel Jacobowitz
2003-03-06  0:56       ` Andrew Cagney
2003-03-06  1:04         ` Daniel Jacobowitz
2003-03-06  1:44           ` Andrew Cagney [this message]
2003-03-06  1:49             ` Daniel Jacobowitz
2003-03-06  1:27         ` J. Johnston
2003-03-06 20:17           ` Andrew Cagney
2003-03-06 20:21             ` Daniel Jacobowitz
2003-03-11  0:00               ` J. Johnston
2003-03-11 14:30                 ` Andrew Cagney
2003-04-15 21:43                   ` Andrew Cagney

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3E66A811.8030203@redhat.com \
    --to=ac131313@redhat.com \
    --cc=drow@mvista.com \
    --cc=gdb@sources.redhat.com \
    --cc=jjohnstn@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox