This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [1/7] Register the main thread/task in fork-child.c


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]