Re: Q: mutlithreaded tracees && clone/exit

[Oleg Nesterov <oleg at redhat dot com>]

On 07/19, Jan Kratochvil wrote:
>
> On Fri, 16 Jul 2010 22:51:47 +0200, Oleg Nesterov wrote:
> > In case this matters, I used gdb-7.1 for testing.
>
> FSF GDB (not Fedora/RHEL GDB) probably.

Yes.

> > Q1: if gsbstub reported that the tracee has exited (say, we sent
> > '$X09#..' to gdb), can gsbstub assume it can forget about this thread?
>
> `X' is about processes, not threads ('W'=TARGET_WAITKIND_EXITED,
> 'X'=TARGET_WAITKIND_SIGNALLED).

Yes, I meant process, not thread. But see below.

> TARGET_WAITKIND_EXITED and TARGET_WAITKIND_SIGNALLED in
> handle_inferior_event() call target_mourn_inferior(), this is very terminal.

OK, but my question was more about the protocol in general.

> > Looking at gdb sources/behaviour, I think the answer is yes, it can
> > forget. But I'd like to have the confirmation.
>
> Yes, I also think so.  I cannot give the confirmation.

OK, thanks.

> > And. I'd like to let you know that gdb is buggy ;)
>
> Please file those bugs while discussing them here:
> 	http://sourceware.org/bugzilla/enter_bug.cgi?product=gdb

Will do.

> > The main question is, I do not understand how gdbstub should handle the
> > multithreaded targets.
> [...]
> > 	(gdb) file test1
> > 	(gdb) target extended-remote :2000
> > 	(gdb) attach 16927
> > 	Attached to process 16927
> > 	...
> > 	0x00000033af60e57d in pause () from /lib64/libpthread.so.0
> > 	(gdb)
> >
> > OK. gdbserver ptraces both threads. But afaics gdb doesn't now this
> > program is multithreaded,
>
> > Q2: Shouldn't gdbstub let debugger know about sub-threads somehow?
>
> gdb did not ask for it so why gdbserver should tell gdbserver it?

Agreed. Although it is not clear to me why gdb did not ask. I mean,
I was surprised just because this doesn't match my naive expectations.

> (gdb) info threads
> [New Thread 14739.14740] <-- GDB has notified it now.
>   2 Thread 14739.14740  0x000000349e8a6a6d in nanosleep () at ../sysdeps/unix/syscall-template.S:82
> * 1 Thread 14739.14739  0x000000349f007fbd in pthread_join (threadid=140515741927184, thread_return=0x0) at pthread_join.c:89
>
> Eclipse apparently does `info threads' over MI

Just curious, what is Eclipse and MI ?

> > gdbserver resumes both threads. Press enter, the sub-thread exits.
> >
> > And nothing happens! gdbserver sends nothing to gdb, it just reaps
> > the tracee silently:
> ...
> > Q3: is it correct? shouldn't we inform the debugger?
>
> GDB will sooner or later use the 'T' packet (remote_thread_alive) to reclaim
> dead threads.

Yes, I know. And when it discovers that the thread has exited, it
sends qfThreadInfo and reconstructs the thread list.

Probably this is fine for gdb. But ugdb was started to prototype the
new general purpose API. Say, vAttach attaches the whole thread group,
there is no way to debug a single thread. Not good in general. The same
for D command and for W/X notifications from gdbserver.

That is why I asked these questions.

And in fact this doesn't look good to me even for gdb. But! please note
that I never used gdb before, it is very possible I am doing something
wrong.

Using the same test-case, I did

	(gdb) set non-stop
	(gdb) file test1
	(gdb) target extended-remote :2000
	(gdb) attach 16339
	(gdb) info threads
	  2 Thread 16339.16340  0x000000375fad65cb in read () from /lib64/libc.so.6
	* 1 Thread 16339.16339  0x00000033af60e57d in pause () from /lib64/libpthread.so.0
	(gdb) c
	Continuing.

Now, gdb sends vCont;c:p3fd3.3fd4 and resumes the single thread,
this is fine.

However, when this thread exits, gdbserver sends nothing and gdb
continues to wait. For what? Another (main) thead is TASK_TRACED,
it can do nothing unless it is SIGKILLED.

> > Q4: is this what we want to implement?
>
> IMO yes, we should first get ugdb a bit on-par with linux-nat.c, don't we?

Yes, agreed. It doesn't make sense to extend the current protocol,
we can't test the extensions until we hack gdb.

> > I have already looked at this code in horror. I really hope this magic
> > is not needed for our purposes.
> >
> > It is gdbserver, not gdb, who uses libthread_db to find sub-threads and
> > do other things.
> >
> > 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.

Of course. The kernel-based API should not be tied to any user-level
libraries/etc.

But more importantly, at first glance this is not needed. At least,
ugdb doesn't need any external help to track exit/clone/etc or to
find all threads in the thread group.

Oleg.