Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: pedro@codesourcery.com
Cc: gdb-patches@sourceware.org
Subject: Re: [1/7] Register the main thread/task in fork-child.c
Date: Fri, 08 Aug 2008 21:47:00 -0000	[thread overview]
Message-ID: <200808082145.m78LjqWQ012096@brahms.sibelius.xs4all.nl> (raw)
In-Reply-To: <200808080233.48834.pedro@codesourcery.com> (message from Pedro 	Alves on Fri, 8 Aug 2008 02:33:48 +0100)

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Fri, 8 Aug 2008 02:33:48 +0100
> 
> Hi,
> 
> This patch makes it so that right after a fork-child, we add the main
> task of the inferior to GDB's thread tables.  We don't have lwp or thread
> info at this point, which means that targets should decorate more of
> inferior_ptid as soon as they have the chance.  Some targets will do it
> as soon as we get to the first target_wait, others, will only have
> info available when a thread library is loaded.
> 
> The issue of changing inferior_ptid to accomodate a new ptid that
> represents the same task, in GDB's perspective is not new.  See below for
> examples are all over the place.
> 
> Since we're now making sure inferior_ptid is always in the thread list,
> when we update it to include more lwp or tid info, we also need to make
> sure that entry in the thread list is updated.  In addition, if there are
> other GDB's sub-components that were holding info on this thread, we should
> be able to inform them of the ptid change.  Hence, I'm adding a new
> thread_change_ptid function, which takes care of updating the thread table,
> and a new observer that is called by this function, so other modules can
> react:
> 
>  @deftypefun void thread_ptid_changed (ptid_t @var{old_ptid}, ptid_t   
>  @var{new_ptid}) 
>  The thread's ptid has changed.  The @var{old_ptid} parameter specifies
>  the old value, and @var{new_ptid} specifies the new value.
>  @end deftypefun
> 
> OK, when the rest of the series is OK?

Heh, I had the exact same fork-child.c change in my tree, but didn't
post a patch yet since I didn't check out yet how this affected Linux.
So that bit must be ok!

The observer makes sense to me too.  So the overall answer is yes!

I'll try to look at the bsd-uthread diff ASAP.


> 2008-08-08  Pedro Alves  <pedro@codesourcery.com>
> 
> 	gdb/doc/
> 	* observer.texi (thread_ptid_changed): New.
> 
> 	gdb/
> 	* gdbthread.h (thread_change_ptid): Declare.
> 	* infrun.c (infrun_thread_ptid_changed): New.
> 	(_initialize_infrun): Attach infrun_thread_ptid_changed to the
> 	thread_ptid_changed observer.
> 	* linux-nat.c (linux_nat_wait): Update inferior_ptid's ptid with
> 	thread_change_ptid.  Don't add or mark the main thread as running
> 	and executing here.
> 	* regcache.c (regcache_thread_ptid_changed): New.
> 	(_initialize_regcache): Attach regcache_thread_ptid_changed to the
> 	thread_ptid_changed observer.
> 	* thread.c (thread_change_ptid): New.
> 	* fork-child.c (fork_inferior): Add the main thread here, and set
> 	it running and executing.


  reply	other threads:[~2008-08-08 21:47 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-08-08  1:33 Pedro Alves
2008-08-08 21:47 ` Mark Kettenis [this message]
2008-08-18 22:41   ` Pedro Alves
2008-08-18 22:44     ` Pedro Alves
2008-08-18 23:23       ` Daniel Jacobowitz
2008-08-18 23:30         ` Pedro Alves

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=200808082145.m78LjqWQ012096@brahms.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb-patches@sourceware.org \
    --cc=pedro@codesourcery.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