Re: Q: multiple inferiors, all-stop && vCont

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Mon, 26 Jul 2010 16:27:59 +0200, Oleg Nesterov wrote:
> For example, I spent several hours trying to understand why gdb
> ignores '%Stop:' notification and never sends '$vStopped', but
> it does send vStopped to the real gdbserver with the same batch
> file. The reason was partly my misunderstanding, but also another
> bug in gdb and the timing issues.

Which bug in gdb do you mean?  I do not have the problem reproducible, the
logs look OK.
	=> $vCont;t:p5b84.-1
	<= $OK
	<= %Stop:T00thread:p5b84.5b84;
	=> $vStopped
	<= $T00thread:p5b84.5b87;
	=> $vStopped
	<= $OK

Are you aware of the comment before remote_get_pending_stop_replies()?


> Or vAttach in the multithreaded case. I'd say that gdbserver is just
> wrong here, even if this works in practice. The first qfThreadInfo
> after vAttach reports only the main thread.

Yes...

OK:
getpkt ("qXfer:threads:read::0,fff");  [no ack sent]
putpkt ("$l<threads>
<thread id="p5baa.5baa" core="2"/>
</threads>
#de"); [noack mode]

> After the first
> vCont;t:PID.-1 only the main thread is reported again. Somehow it
> provokes gdb to send more 'vCont;t:PID.-1's packets, only then it
> reports the new threads via Stop/vStopped.

Only after GDB issues:

->server: getpkt ("qSymbol::");  [no ack sent]
[...]
<-server: putpkt ("$qSymbol:5f7468726561645f64625f6c6973745f745f6e657874#a0"); [noack mode]
                            = _thread_db_list_t_next
->server: getpkt ("qSymbol:7f4c9a0ab0bc:5f7468726561645f64625f6c6973745f745f6e657874");  [no ack sent]
                                        = _thread_db_list_t_next

gdbserver can ask GDB for some symbols the gdbserver needs to provide to
libthread_db to be able to find out all the inferior threads using
libthread_db calling back gdbserver's ps_pglobal_lookup.

	`qSymbol::'
	     Notify the target that GDB is prepared to serve symbol lookup
	     requests.  Accept requests from the target for the values of
	     symbols.

Immediately at the moment of vAttach GDB may not be able to answer those
questions so it is delayed a bit.


> At first I tried to mimic this behaviour, I was already totally
> confused because I also had other problems with gdb - it constantly
> crashed. But finally I have found that the simple approach seems to
> work too.

Yes, I see:

gdb=> $vAttach;5bb7
gdb<= $OK
gdb=> $qfThreadInfo
gdb<= $mp5bb7.5bb7,p5bb7.5bba
gdb=> $qsThreadInfo
gdb<= $l
[...]
gdb=> $qSymbol::
gdb<= $


Even FSF gdbserver does not seem to use/provide pthread_t identifiers:
  2 Thread 23487.23490  0x00007fb25c983a6d in nanosleep () at ../sysdeps/unix/syscall-template.S:82
* 1 Thread 23487.23487  0x00007fb25cc63fbd in pthread_join (threadid=140404033701648, thread_return=0x0) at pthread_join.c:89

as provided by local linux-nat.c / linux-thread-db.c.
  2 Thread 0x7ffff7842710 (LWP 23503)  0x00007ffff78e9a6d in nanosleep () at ../sysdeps/unix/syscall-template.S:82
* 1 Thread 0x7ffff7ff3700 (LWP 23500)  0x00007ffff7bc9fbd in pthread_join (threadid=140737346021136, thread_return=0x0) at pthread_join.c:89

The LWP -> thread_t conversion could be done later from the client side only
using:
libthread_db (td_ta_map_lwp2thr(), td_thr_get_info(),
              typeof (td_thrinfo_t->ti_tid) = thread_t)


> Right now I am trying to understand why gdb doesn't use 'vCont:c'
> but sends 'c' instead. And yes, I report 'vCont;c;t' to 'vCont?'.

GDB can use both, why do you want from GDB to use specifically `vCont:c'?
`c' uses the inferior-kind specified by `Hc' (server'c cont_thread).


Thanks,
Jan