Re: Q: mutlithreaded tracees && clone/exit

[Roland McGrath <roland at redhat dot com>]

[I trimmed the CC because everybody concerned should be on this list.]
 
> In case this matters, I used gdb-7.1 for testing.

I'm not the gdb expert.  So I'll just say what I think is reasonable,
and then we'll figure out where we need to change our thinking and
where need to get gdb changed.

> Q1: if gsbstub reported that the tracee has exited (say, we sent
> '$X09#..' to gdb), can gsbstub assume it can forget about this thread?

I think so.  In the ptrace-based implementation of gdbserver, it sends
X or W reports after it has done wait and gotten a death status.  In
Linux, that means the zombie is reaped and its PID is available for reuse.

> The main question is, I do not understand how gdbstub should handle the
> multithreaded targets.

It's not really clear to me when gdb decides to ask for the thread
list.  It looks like it only does it at extended-remote attach time if
you have set non-stop mode.

> Q2: Shouldn't gdbstub let debugger know about sub-threads somehow?

That's what I would expect in the abstract.  But I know that gdb
didn't used to get new-thread notifications from ptrace either.  It
looks like the linux-nat code does track PTRACE_EVENT_CLONE now.
But it may be that the gdbserver code and remote protocol were made
to match how things were when the native ptrace case didn't do that.

gdb also uses higher-level knowledge read from user memory
(libthread_db) for some aspects of thread tracking.  I really don't
know how the kernel-thread layer and the thread_db layer fit together
in gdb at this point.  But certainly historically it had means to get
by without kernel facilities either for enumerating the live threads
or for notifying of thread creation and death.  libthread_db instructs
gdb based on libpthread details read from the user memory, to extract
the thread list and TIDs, and to set breakpoints in libpthread to tell
it about thread creation and death.  All that should be superfluous
when proper low-level thread (LWP in gdbspeak) tracking is being done.
But it's there historically, so in practice gdb could get by without
whichever low-level layer (ptrace or remote or whatever) helping it.

> I am asking because that I thought that gdb+gdbserver should
> try to work the same way as it works without gdbserver, and
> thus it should see clone/exit.

I agree that's how it seems it should be.


Thanks,
Roland