On Monday 07 July 2008 19:20:09, Daniel Jacobowitz wrote:
> On Wed, Jul 02, 2008 at 04:34:50AM +0100, Pedro Alves wrote:

> > @@ -1720,20 +1811,54 @@ linux_handle_extended_wait (struct lwp_i
> >  	  else
> >  	    status = 0;
> >
> > +#if 0
> > +	  /* Make thread_db aware of this thread.  We do this this
> > +	     early, so in non-stop mode, threads show up as they're
> > +	     created, instead of on next stop, and so that they have
> > +	     the correct running state.  thread_db_find_new_threads
> > +	     needs a stopped inferior_ptid --- since we know LP is
> > +	     stopped, use it this time.  */
> > +	  old_chain = save_inferior_ptid ();
> > +	  inferior_ptid = lp->ptid;
> > +	  lp->stopped = 1;
> > +	  target_find_new_threads ();
> > +	  do_cleanups (old_chain);
> > +	  if (!in_thread_list (new_lp->ptid))
> > +#else
> > +	  /* "Attach"ing to the parent forces the thread_db target to
> > +	     build its private data structures for the parent, which
> > +	     may have not had them setup yet.  */
> > +	  thread_db_attach_lwp (lp->ptid);
> > +	  /* Do the same to the child, which, if thread_db is active,
> > +	     adds the child to GDB's thread list.  */
> > +	  if (!thread_db_attach_lwp (new_lp->ptid))
> > +#endif
>
> This (the thread_db_attach_lwp version) looks reasonable to me.  Ugly,
> but reasonable.  Why do we need the parent's data?

Due to this:

 (gdb) r&
 Starting program: /home/pedro/gdb/tests/threads32
 (gdb) [Thread debugging using libthread_db enabled]
 [New Thread 0xf7df0b90 (LWP 24154)]
 [New Thread 0xf75efb90 (LWP 24155)]
 info threads
   3 Thread 0xf75efb90 (LWP 24155)  (running)
   2 Thread 0xf7df0b90 (LWP 24154)  (running)
 * 1 LWP 24151  (running)
 (gdb) interrupt
 (gdb)
 Program received signal SIGINT, Interrupt.
 0xffffe410 in __kernel_vsyscall ()
 info threads
 During symbol reading, incomplete CFI data; unspecified registers (e.g., eax) at 0xffffe411.
   3 Thread 0xf75efb90 (LWP 24155)  (running)
   2 Thread 0xf7df0b90 (LWP 24154)  (running)
 * 1 Thread 0xf7df16b0 (LWP 24151)  0xffffe410 in __kernel_vsyscall ()

This is where I had gotten myself stuck.  The main thread id
isn't discovered until late when we stop.  The thing is that the main
thread is already in GDB's thread list since very early, before
thread_db was detected.  Since we can only query thread_db when we
have a stopped thread around, I couldn't find any other place to
learn about the main thread's thread_db id, until it has stopped.
Even doing it on PTRACE_EVENT_CLONE doesn't solve the
single-threaded + thread_db case.

Also, this happened:

(gdb) b 81
Breakpoint 1 at 0x80485fd: file threads.c, line 81.
(gdb) r
Starting program: /home/pedro/gdb/tests/threads32
[Thread debugging using libthread_db enabled]
[New Thread 0xf7dd8b90 (LWP 28225)]
[New Thread 0xf75d7b90 (LWP 28226)]

Breakpoint 1, thread_function1 (arg=0x1) at threads.c:81
81              usleep (1);  /* Loop increment.  */
(gdb) info threads
  3 Thread 0xf75d7b90 (LWP 28226)  thread_function1 (arg=0x1) at threads.c:81
  2 Thread 0xf7dd8b90 (LWP 28225)  (running)
* 1 LWP 28222  (running)

The issue here is that have_threads returns true here:

linux-thread-db.c:thread_db_wait
...
  /* If we do not know about the main thread yet, this would be a good time to
     find it.  */
  if (ourstatus->kind == TARGET_WAITKIND_STOPPED && !have_threads ())
    thread_db_find_new_threads ();

... because there are already threads that thread_db learned about,
so we'd not look for info regarding the main thread.

The attached patch fixes these issues, by changing this bit above
to do:

  if (ourstatus->kind == TARGET_WAITKIND_STOPPED)
    /* If we do not know about the main thread yet, this would be a
       good time to find it.  */
    iterate_over_threads (thread_db_claim_lwp_callback, &ptid);

... and adds the necessary glue for that.


>
> > +	    {
> > +	      /* We're not using thread_db.  Attach and add it to
> > +		 GDB's list.  */
> > +	      lin_lwp_attach_lwp (new_lp->ptid);
> > +	      target_post_attach (GET_LWP (new_lp->ptid));
> > +	      add_thread (new_lp->ptid);
> > +	    }
> > +
>
> Why do we need to call lin_lwp_attach_lwp?  Won't that try to
> PTRACE_ATTACH?  And we've already called add_lwp above.

It won't do PTRACE_ATTACH, exactly because we've already
called add_lwp above.  Ah, I see.  lin_lwp_attach_lwp will
only do lp->stopped = 1 in this case, the "attach to every
thread" thing is meant for the target_attach'ing case.  I've
removed that call.

Apart from the what's mentioned above, nothing else changed.
Does the patch look closer to ok now?

I've regtested it on x86_64-unknown-linux-gnu.

-- 
Pedro Alves