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

[Oleg Nesterov <oleg@redhat.com>]

On 08/03, Jan Kratochvil wrote:
>
> 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?

Heh. Funny that, I just sent another email which explains how I was
confused (in reply to my first "Q: %Stop && gdb crash" message).

> 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

Yes, this is OK. And this is how this all works when I enter the
commands via CLI (probably -ex works too).

> Are you aware of the comment before remote_get_pending_stop_replies()?

Well, I read it before, but I was never able to parse it up to the end ;)

> > 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.

Yes, I know.

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

Yes, I have to take my "gdbserver is just wrong" back.

However, I do not really understand how this can work reliably in the
terms of remote protocol. Somehow this scheme relies on the fact that
gdb will send another vCont;t:pTGID.-1 _once again_ after the previous
vCont;t:pTGID.-1, and gdbserver can report the other threads via
Stop/vStopped. OK, I hope this doesn't matter.

> > 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<= $

Yes. And please note that at least in-kernel gdbstub can not use
libthread_db. But, I also hope that we can avoid it even if gdbstub
runs in user-space ?

> 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)

Cough. This is black magic to me ;)

I probably understand what pthread_t is, but I do not know how/if this
is important for gdb.

Should I worry about this issue right now?

And, I hope that "client side only using: libthread_db" means gdb, not
gdbserver ?

> > 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,

Yes, I know.

> why do you want from GDB to use specifically `vCont:c'?

Because, first of all, I wanted to understand why gdb doesn't send
vCont:c to me, but uses this command when it works with the real
gdbserver.

Also, I am trying to identify the "essential" commands subset.
Afaics, vCont:c is preferred, and gdb never uses 'c' if it knows
it can use 'vCont:c'.

And. How could I verify that I handle vCont:c correctly if I wasn't
able to provoke gdb to send it?

Oleg.