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:04:00 -0000 [thread overview]
Message-ID: <20030306010428.GA17878@nevyn.them.org> (raw)
In-Reply-To: <3E669CA1.2010201@redhat.com>
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
next prev parent reply other threads:[~2003-03-06 1:04 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 [this message]
2003-03-06 1:44 ` Andrew Cagney
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=20030306010428.GA17878@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