From: Daniel Jacobowitz <drow@mvista.com>
To: Andrew Cagney <ac131313@redhat.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:49:00 -0000 [thread overview]
Message-ID: <20030306014947.GA952@nevyn.them.org> (raw)
In-Reply-To: <3E66A811.8030203@redhat.com>
On Wed, Mar 05, 2003 at 08:44:49PM -0500, Andrew Cagney wrote:
> >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)
Makes sense.
> Each has something like:
>
> - an architecture
> - a target
> - an owner?
Not sure...
> >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).
Good luck, it's been on my list for a year and a half or so and every
time I try I get scared and find something else to do.
> >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?
I disconnected from myself there. Event -> lwp layer -> thread layer;
GDB request -> thread layer -> lwp layer.
> >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.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
next prev parent reply other threads:[~2003-03-06 1:49 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
2003-03-06 1:49 ` Daniel Jacobowitz [this message]
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=20030306014947.GA952@nevyn.them.org \
--to=drow@mvista.com \
--cc=ac131313@redhat.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