Re: Q: mutlithreaded tracees && clone/exit

[Roland McGrath <roland@redhat.com>]

> This issue does not work well even with linux-nat.c (local GDB), in the
> current development stage of ugdb I believe we do not have to solve it before
> linux-nat.c gets fixed first:
> 	GDB hangs with simple multi-threaded program on linux
> 	http://sourceware.org/ml/gdb/2010-07/msg00045.html

On the contrary, this is something where not being ptrace makes an
important difference.  The ptrace behavior that makes this difficult to
deal with in linux-nat.c is not at all an inherent issue with the scenario,
it's just a quirk of the ptrace interface.  The fact that linux-nat.c
doesn't handle it well means that it's not a big priority to handle it
better than that.  But it's certainly not the case that linux-nat.c
improving its support would have anything to do with how ugdb would do it.

> GDB will sooner or later use the 'T' packet (remote_thread_alive) to reclaim
> dead threads.

For this to be correct, it must be using multiprocess mode so that its
packet says Tn.m instead of just Tm.  In the latter case, the TID m may
have been reused for an unrelated new thread.

> IMO yes, we should first get ugdb a bit on-par with linux-nat.c, don't we?

Sure.  But we should carefully note all the ways in which that standard of
comparison is less than ideal.

> > gdbserver asks gdb what is the symbol's address (say, _thread_db_list_t_next)
> > via 'qSymbol'.
> 
> i see this can be a problem for ugdb.  Guessing we will need to change GDB to
> support new variant of proc-service.c working over the GDB protocol wire.

proc-service.c is already written in terms of the gdb target backend.
I had presumed that all this thread_db layer of concern would happen
above the LWP layer, and the remote protocol supplies the LWP layer.


Thanks,
Roland