Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Mark Kettenis <kettenis@gnu.org>, gdb-patches@sources.redhat.com
Subject: Re: [rfa] Include the LWP in thread-db's PTIDs
Date: Sun, 17 Oct 2004 19:19:00 -0000	[thread overview]
Message-ID: <20041017191941.GB23601@nevyn.them.org> (raw)
In-Reply-To: <20041013212714.GA4722@nevyn.them.org>

On Wed, Oct 13, 2004 at 05:27:15PM -0400, Daniel Jacobowitz wrote:
> On Wed, Oct 13, 2004 at 11:16:05PM +0200, Mark Kettenis wrote:
> >    Date: Tue, 12 Oct 2004 09:31:40 -0400
> >    From: Daniel Jacobowitz <drow@false.org>
> > 
> >    On Mon, Oct 11, 2004 at 09:40:26PM +0200, Mark Kettenis wrote:
> >    > 
> >    > I think assuming 1:1 threads is fair enough.  But Daniel, if you're
> >    > going to do that, I'd like to ask you to rename thread-db.c into
> >    > linux-thread.c or something like that.
> > 
> >    How about glibc-thread-db.c?
> > 
> > I'm not sure whether that's appropriate.  NPTL is defenitely
> > Linux-specific.  The Hurd doesn't have a thread_db yet.  I suppose
> > that if you're going to make some Linux-specific assumptions
> > glibc-thread-db.c isn't right.
> 
> I was not planning on making any Linux-specific assumptions in the
> thread-db code - just in lin-lwp.  I doubt glibc's thread_db
> implementation is going to support non-1:1 threading, and that's the
> only assumption I am planning on using in what is now thread-db.c.
> 
> But I don't know much about threading for the only active non-Linux
> users of glibc (the kBSD projects and the Hurd).  Do you think that the
> 1:1 assumption is Linux-specific rather than glibc-specific?  If so,
> linux-thread-db.c would be a better choice indeed, and I can use that.

Ping on the renaming question.

I think that I should take care of the renaming of this file before I
start adding assumptions to it, so I withdraw the patch at the
beginning of this thread until that has been taken care of.

> >    Anyway, I'm wondering if there should be some other method of
> >    communication between the native and thread strata (as opposed to
> >    between lin-lwp and thread_db!).  I don't much want to use to_wait for
> >    this, because the assumption in the rest of GDB is that to_wait returns
> >    when all threads are stopped and I don't want to gratuitously stop all
> >    threads when we receive a creation event.
> > 
> > But you don't have to return from to_wait upon a creation event.  But
> > we probably should if the user asks us to report new threads.  The
> > current way of printing [new thread] messages is a bit broken, since
> > GDB doesn't always have control over the terminal.
> 
> Indeed, we don't have to return from to_wait after thread creation. 
> However, if there are thread strata above us, we want to report the new
> thread to them promptly.  For instance, the thread-db layer should
> always (when in use) sit between lin-lwp and GDB for thread reporting,
> so that threads are reported with the correct TID.
> 
> [It's a little more complicated than that, in this case.  The TID is
> not available quite as early as the LWP is, so we have the LWP without
> its corresponding thread.  So GDB might have to handle the thread IDs
> changing during its lifetime; ew.]

I'm still thinking about this bit...

-- 
Daniel Jacobowitz


  reply	other threads:[~2004-10-17 19:19 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-10 21:36 Daniel Jacobowitz
2004-10-11 15:29 ` Andrew Cagney
2004-10-11 15:38   ` Daniel Jacobowitz
2004-10-11 15:55     ` Joel Brobecker
2004-10-11 16:17     ` Andrew Cagney
2004-10-11 17:12       ` Daniel Jacobowitz
2004-10-11 18:29         ` Andrew Cagney
2004-10-12 13:26           ` Daniel Jacobowitz
2004-10-11 19:40   ` Mark Kettenis
2004-10-12 13:31     ` Daniel Jacobowitz
2004-10-13 21:16       ` Mark Kettenis
2004-10-13 21:27         ` Daniel Jacobowitz
2004-10-17 19:19           ` Daniel Jacobowitz [this message]
2004-10-13 21:37     ` Paul Gilliam
2004-11-14 19:17 ` Daniel Jacobowitz
2004-12-02 21:16   ` Michael Snyder
2004-12-08 16:14     ` Daniel Jacobowitz

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=20041017191941.GB23601@nevyn.them.org \
    --to=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=kettenis@gnu.org \
    /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