fix attach in remote non-stop mode in some cases

Pedro Alves pedro@codesourcery.com
Wed Nov 5 20:27:00 GMT 2008


Hi,

"attach" in non-stop mode wasn't working correctly against a stub we're
developing.  This target doesn't stop threads implicitly on a vAttach,
and it happened that the thread that we installed the continuation on,
wasn't the first thread that reported a stop event, which made it so
that all stop events prior to the one we installed to continuation on
didn't go through normal_stop, hence we didn't tag those threads as
stopped, although they were.  A follow up "c -a" wouldn't resume those
threads, as GDB thought they were already running.  The stub's behaviour
is perfectly legal, but GDB wasn't coping with it.

That attached patch fixes it, by adding new per-inferior
continuations for the situation that we want to do something on the
next stop of the inferior, doesn't matter which thread.

In addition, since GDB stopped the inferior explicitly,
the inferior reported "signal 0" on each thread stop, but GDB wasn't
considering it a normal signal to get in that case, which made it
so that "attach&" printed one thread stop, while it should have been
silent.

Tested on native x86-pc-linux-gnu, sync, async, all-stop/non-stop,
and checked in.

-- 
Pedro Alves
-------------- next part --------------
A non-text attachment was scrubbed...
Name: attach_nonstop.diff
Type: text/x-diff
Size: 7856 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/gdb-patches/attachments/20081105/caec7673/attachment.bin>


More information about the Gdb-patches mailing list