Hi,

This patch fixes several issues I noticed with attaching
to processes with gdbserver's --multi support, on several
host/target combinations:

Linux host -> Linux gdbserver

 There's code in gdbserver to pretend the initial SIGSTOP
 was a SIGTRAP, that's been put there so
 "gdbserver --attach PID"; "target remote", doesn't see
 the SIGSTOP.  This smudging should not be done when
 handling a vAttach, otherwise, the user is presented
 with:

 (gdb) tar extended-remote :9999
 Remote debugging using :9999
 (gdb) attach 32762
 Attached to Thread 32762
 [New Thread 32762]

 Program received signal SIGTRAP, Trace/breakpoint trap.
 0x00007fc30f5d0b30 in ?? ()

 ... a bogus SIGTRAP.

Linux host -> Windows gdbserver

 - On Windows, the signal we get while attaching when the inferior gets
   stopped is really a SIGTRAP.  In this case, we do want do convert it
   to a SIGSTOP, so GDB suppresses it.

 - Due to the fact that ATTACH_NO_WAIT is a host macro (it shouldn't, and
   I'm posting a patch next to fix that), and it being defined in
   Windows hosts, the T stop reply packet gdbserver sends after attaching
   is just ignored on the GDB side.  On most other hosts (except hurd),
   ATTACH_NO_WAIT is not defined, which reveals a buglet that had
   gotten unnoticed.

 (gdb) tar extended-remote sandra:9999
 Remote debugging using sandra:9999
 (gdb) attach 988
 Attached to Thread 988
 [New Thread 2232]

 Program received signal 0, Signal 0.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 Error while mapping shared library sections:
 /cygdrive/c/WINDOWS/system32/ntdll.dll: No such file or directory.
 Error while mapping shared library sections:
 /cygdrive/c/WINDOWS/system32/kernel32.dll: No such file or directory.
 ...
 /usr/bin/cygiconv-2.dll: No such file or directory.
 Symbol file not found for /cygdrive/c/WINDOWS/system32/ntdll.dll
 Symbol file not found for /cygdrive/c/WINDOWS/system32/kernel32.dll
 ...
 [Switching to Thread 2232]
 Stopped due to shared library event
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

 On initial connections, we're preventing gdbserver to report
 dll changes in the T stop reply packet, because GDB will always query
 the dll list anyway.  We missed doing that on vAttach handling.
 The "signal 0" notice happens even though gdbserver sends T05, because
 the stop reason is transformed into a TARGET_WAITKIND_LOADED, and the
 signal number sent isn't really parsed (from remote.c):

	  if (solibs_changed)
	    status->kind = TARGET_WAITKIND_LOADED;
	  else
	    {
	      status->kind = TARGET_WAITKIND_STOPPED;
	      status->value.sig = (enum target_signal)
		(((fromhex (buf[1])) << 4) + (fromhex (buf[2])));


Windows host -> Windows gdbserver

 Due to ATTACH_NO_WAIT being defined, the T stop reply
 gdbserver sends on attaches is just being ignored.  That's why
 the "stopped by library event" notice bug went unnoticed.
 I had worked on the Windows port of --multi for gdbserver
 from a Windows host :-)
 I'm posting a patch next that gets rid of ATTACH_NO_WAIT, which
 then triggers the same "problems" as seen while attaching
 to a Windows gdbserver from a Linux host.

Windows host -> Linux gdbserver

 Same rationale as above.

Tested manually on all those combinations, and regression tested
with local gdbservers on x86_64-unknown-linux-gnu, x86-pc-cygwin.

OK?

-- 
Pedro Alves