This is the mail archive of the
mailing list for the Archer project.
Re: Q: mutlithreaded tracees && clone/exit
> 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
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.