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: [RFC][Patch] Fix gdb failure to access tls data for parent thread


On Mon, 2009-02-23 at 09:08 -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 23, 2009 at 02:20:59PM +0530, Vinay Sridhar wrote:
> > > If they are, and they do not have private info set, what added them to
> > > the thread list?  I missed one function; maybe they were added by
> > > add_thread_silent?
> > > 
> > 
> > yes, add_thread_silent () is called on the threads. Its called for the
> > parent from fork_inferior () and for the child threads from
> > add_thread_with_info ()
> 
> Thanks, now we're making progress.
> 
> Pedro, copying you because this is related to always-a-thread.
> 
> What's happening here is that we go to look up a TLS variable.
> We have some threads in the thread list with thread->private set, but
> the main thread does not have it set - thread_db never added it,
> fork_inferior did.  So we don't really know about it.
> 
> Vinay, thread_db_find_new_threads should have been called when the
> program started up. 

ïYes, I did see thread_db_find_new_threads being called.

>  Was find_new_threads_callback called for
> the main thread during that process?  If so, was ti_tid == 0?
> That shouldn't happen unless the program is staticly linked.
> 

find_new_thread_callback was called on the parent thread, before the
other threads were initialised. (I was able to trace 2 of these calls on
the parent thread though, not sure why). And yes, "ti_tid" was set to 0
for the parent thread. 



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