Re: [RFC][Patch] Fix gdb failure to access tls data for parent thread

[Daniel Jacobowitz <drow@false.org>]

On Tue, Feb 24, 2009 at 04:20:10PM +0530, Vinay Sridhar wrote:
> Please try this test and let me know if you're able to get a recreate:

I can reproduce this.  Here's where we ought to discover the thread:

1012      /* Iterate over all user-space threads to discover new threads.  */
1013      err = td_ta_thr_iter_p (thread_agent, find_new_threads_callback, NULL,
1014                              TD_THR_ANY_STATE, TD_THR_LOWEST_PRIORITY,
1015                              TD_SIGNO_MASK, TD_THR_ANY_USER_FLAGS);

The first two times this is called, ti_tid is 0 for the main thread,
so we do nothing.  The third time, find_new_threads_callback
is never called!  The thread library is claiming we have no threads.
Repeating "info threads" again has the same effect:

  5 Thread 0x7ffff5c5f950 (LWP 7440)  0x00007ffff7bde9c7 in ?? () from
  /usr/lib/libgomp.so.1
  4 Thread 0x7ffff6460950 (LWP 7439)  initTlsData () at omp-test.c:9
  3 Thread 0x7ffff6c61950 (LWP 7438)  0x00007ffff7bdea1a in ?? () from
  /usr/lib/libgomp.so.1
  2 Thread 0x7ffff7462950 (LWP 7418)  0x00007ffff7bdea1a in ?? () from
  /usr/lib/libgomp.so.1
* 1 LWP 7410  0x00007ffff7bdea1a in ?? () from /usr/lib/libgomp.so.1

Pedro, unfortunately this bug is related to non-stop :-(

81            /* Verify that this thread's pid field matches the child PID.
82               If its pid field is negative, it's about to do a fork or it
83               is the sole thread in a fork child.  */

It's checking that the PID (not TID) matches proc_handle.pid.  We need
to find another way to read from a stopped thread, since if we put any
other PID there, we get no threads.  I would suggest expanding
ps_prochandle to include a memory thread as ptid_t.  We always try to
read from the most recently added stopped thread, since the lwp_list
gets additions at the front.

-- 
Daniel Jacobowitz
CodeSourcery