This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: BUG? gdb, non-stop && c -a
On 07/20, Jan Kratochvil wrote:
>
> On Tue, 20 Jul 2010 16:47:38 +0200, Oleg Nesterov wrote:
> > On 07/20, Jan Kratochvil wrote:
> > > > this sends "vCont;c:p4745.4746" but not "vCont;c:p4745.-1" as I'd expect.
> > >
> > > Why is this a problem to list all the threads instead of -1?
> >
> > But doesn't list all threads? p4745.4746 is the single thread?
>
> OK, sorry, I am not used to the protocol.
>
> So yes, but it is immediately followed by enxt vCont for the other thread:
> Sending packet: $vCont;c:p4a8f.4a90#b1...Packet received: OK
> [...]
> Sending packet: $vCont;c:p4a8f.4a8f#e6...Packet received: OK
>
>
> > And, in any case, gdbserver resumes only this thread.
>
> It seems to resume both in my case. We should provide better reproducers
>
> killall -9 threadit gdbserver;~/t/threadit&p=$!;./gdbserver/gdbserver --multi :1234&sleep 0.5;./gdb -nx -ex 'set non-stop on' -ex 'set target-async on' -ex 'set debug remote 1' -ex 'file ~/t/threadit' -ex 'target extended-remote :1234' -ex "attach $p"
> (gdb) c-a
>
> sends vCont twice.
Yes. When I added "set target-async on" as you suggested, gdb sends
vConct twice.
And,
> > So, it is not possible to enter the CLI mode again after "c -a" ?
> > (unless the target hits the bp or something, of course).
>
> CTRL-C BTW works for me;
^C works too.
Thanks!
So, I'll assume "set target-async on" must be always used if I want
to test something in !all-stop mode. Afaics, this has nothing to do
with gdbserver, it only affects the behaviour of gdb itself.
Oleg.