This is the mail archive of the
mailing list for the Archer project.
Re: BUG? gdb, non-stop && c -a
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"
sends vCont twice.
> 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; testing FSF GDB HEAD, IMO you should too when I think
about it. Retested it even on FSF GDB 7.1.