This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC][Patch] Fix gdb failure to access tls data for parent thread
On Monday 23 February 2009 14:08:12, 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. 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.
>
I haven't had a chance to investigate this yet, other than building
Vinay's testcase (which doesn't build BTW. Please confirm if there
isn't anything important missing), and noticing I can't reproduce.
Sounds like there's a race somewhere that one of the calls that
look like this:
if (!have_threads ())
thread_db_find_new_threads_1 ();
... is finding that we already have a ->private field set for
some thread not the main, and hence, we're not filling it
for the main thread.
Vinay, could you tell us some more details about your system?
--
Pedro Alves