(gdb) tar rem | asdfasdfa
 Remote debugging using | asdfasdfa
 sh: asdfasdfa: not found
 Remote communication error: Resource temporarily unavailable.
 (gdb) p a
 ../../src/gdb/thread.c:529: internal-error: is_thread_state: Assertion `tp' failed.
 A problem internal to GDB has been detected,
 further debugging may prove unreliable.
 Quit this debugging session? (y or n) 

Ok, doesn't look good, and when I wrote this patch, the symptoms
weren't so bad, but this is really undefined behaviour ...

The big picture: We got ourselves a half-backed target pushed on
the stack.  Not very digestible.

The issue is that we have this remote_start_remote function
that is wrapped in catch_exceptions, where the initial comunication
with the target should be done.  At its call site, we have this
comment:

remote_open_1:

"  /* Start the remote connection.  If error() or QUIT, discard this
     target (we'd otherwise be in an inconsistent state) and then
     propogate the error on up the exception chain.  This ensures that
     the caller doesn't stumble along blindly assuming that the
     function succeeded.
"

But, over time, several possible calls to putpkt/getpkt/error made
its way to remote_open_1, making it possible to leave a
half-backed target pushed when an exception is thrown.

So, the patch looks bigger than it really is.  I'm just mostly
moving things around (but keeping the same sequences).

(The initial acknowleding of any pending ack, which should be the
first thing sent to the stub used to be in remote_start_remote, until
I moved it out, with the noack mode changes, because I had noticed
that it was no longer the first thing being sent.)

Daniel then found out that this made an existing race easier to
trigger.  If the connection is closed while inside
remote_start_remote, readchar calls target_mourn_inferior followed
by throwing an error.  This exception is then caught in the safe
net of remote_open_1 mentioned about, that pops the target.  Problem is,
remote_mourn_1 had already unpushed the target.  This meant that
the second pop could pop the dummy target --- not something that we
should be doing every day.  The following commands would crash, because
the target_stack would be borked.

Tested against a local x86-64-unknown-linux-gnu gdbserver and
checked in.

-- 
Pedro Alves