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