A Wednesday 25 June 2008 23:12:20, Daniel Jacobowitz wrote:

> > That's right, the only thing we'll miss if we do that, is the
> > thread_db id of the thread in output like:
> >
> > [New Thread 0xf7e11b90 (LWP 26100)]
> >              ^^^^^^^^
> > And info threads:
> >
> >   2 Thread 0xf7e11b90 (LWP 26100)  (running)
> >              ^^^^^^^^
> >
> > Those will only show up on the next stop event (of any thread).
> > It may take a while, if all threads are running (unless we do
> > momentarily stop threads trick).
>
> Oh, dear.  Options:
>
>   - delay the notification until thread_db discovers the thread,
>     if libthread_db is already active
>
>   - display the notification without the thread ID; we'll have the
>     LWP ID and we could add the GDB thread number
>
>   - go with your code and fix broken situations as they arise
>
> I'm undecided.  Note that your code is unnecessarily quadratic, by the
> way.  It'll walk the entire thread list; we could just load the new
> thread since we know its LWP ID.  libthread_db may still do a walk in
> that case though...

I'd prefer the third, if it's still on the plate.
I've tried not calling into target_find_new_threads, but wasn't
convinced that the saving justifies the possible ugliness we
introduce.  The walk is most surelly still performed to map an
LWP to a user thread.

If it is justifiable, what is the prefered interface to call
into thread_db in this case?  A new target method?  The double
call I'm making into thread db, is because this may be the
earliest that we can get thread_db info on the main thread (the
parent of the first clone).  I couldn't find another place to
put it that didn't end up introducing more walks.

>
> > > SIGKILL should work even if the thread is stopped.
> >
> > I think I'll need a SIGCONT as well in that case.  For some
> > reason, I wasn't getting that to work all the times.  I'll
> > experiment some more.
>
> Kernels may vary in this regard.  Your code seems reasonable.
> PTRACE_KILL is supposed to be just SIGKILL + PTRACE_CONT, and SIGKILL
> is supposed to work even on stopped processes, but the details come
> and go... as you know, signal handling is a very touchy area and hard
> to write tests for.

I had second thoughts on the code.  It's racy.  If a running thread
happens to stop (and GDB doesn't know about it yet) just before
sending SIGKILL, I'd miss sending PTRACE_CONT in kernels that need
it.  I think it's just better to stop all threads before killing
them, and then killing them like we used to.

Obviously, the patch still needs the new thread management part
to be resolved, but otherwise, it should be done.

-- 
Pedro Alves