From: Pedro Alves <pedro@codesourcery.com>
To: gdb-patches@sourceware.org
Subject: [gdbserver] Fix attaching notices
Date: Fri, 27 Jun 2008 23:26:00 -0000 [thread overview]
Message-ID: <200806280011.12868.pedro@codesourcery.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 3331 bytes --]
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
[-- Attachment #2: gdbserver_attach_notices.diff --]
[-- Type: text/x-diff, Size: 2917 bytes --]
2008-06-28 Pedro Alves <pedro@codesourcery.com>
* server.c (attach_inferior): Add vattach parameter. If attaching
due to a vAttach, don't hide a SIGSTOP, and, if attaching finishes
with a SIGTRAP, pretend it was a SIGSTOP.
(handle_v_attach): Pass 1 as vattach parameter to attach_inferior.
Don't report dll changes.
(main): Pass 0 as vattach parameter to attach_inferior.
---
gdb/gdbserver/server.c | 25 ++++++++++++++++++-------
1 file changed, 18 insertions(+), 7 deletions(-)
Index: src/gdb/gdbserver/server.c
===================================================================
--- src.orig/gdb/gdbserver/server.c
+++ src/gdb/gdbserver/server.c
@@ -160,7 +160,7 @@ start_inferior (char **argv, char *statu
}
static int
-attach_inferior (int pid, char *statusptr, int *sigptr)
+attach_inferior (int pid, char *statusptr, int *sigptr, int vattach)
{
/* myattach should return -1 if attaching is unsupported,
0 if it succeeded, and call error() otherwise. */
@@ -180,11 +180,17 @@ attach_inferior (int pid, char *statuspt
*sigptr = mywait (statusptr, 0);
- /* GDB knows to ignore the first SIGSTOP after attaching to a running
- process using the "attach" command, but this is different; it's
- just using "target remote". Pretend it's just starting up. */
- if (*statusptr == 'T' && *sigptr == TARGET_SIGNAL_STOP)
+ /* GDB knows to ignore the first SIGSTOP after attaching to a
+ running process using the "attach" command, but if we're
+ attaching due to --attach this is different; it's just using
+ "target remote". Pretend it's just starting up. */
+ if (!vattach && *statusptr == 'T' && *sigptr == TARGET_SIGNAL_STOP)
*sigptr = TARGET_SIGNAL_TRAP;
+ /* Similarly, on some targets, attaching finishes with a SIGTRAP
+ (e.g., on Windows it's called the initial breakpoint). Pretend
+ it was a SIGSTOP, so GDB hushes it. */
+ else if (vattach && *statusptr == 'T' && *sigptr == TARGET_SIGNAL_TRAP)
+ *sigptr = TARGET_SIGNAL_STOP;
return 0;
}
@@ -1011,8 +1017,13 @@ handle_v_attach (char *own_buf, char *st
int pid;
pid = strtol (own_buf + 8, NULL, 16);
- if (pid != 0 && attach_inferior (pid, status, signal) == 0)
+ if (pid != 0 && attach_inferior (pid, status, signal, 1) == 0)
{
+ /* Don't report shared library events after attaching, even if
+ some libraries are preloaded. GDB will always poll the
+ library list. Avoids the "stopped by shared library event"
+ notice on the GDB side. */
+ dlls_changed = 0;
prepare_resume_reply (own_buf, *status, *signal);
return 1;
}
@@ -1336,7 +1347,7 @@ main (int argc, char *argv[])
}
else if (pid != 0)
{
- if (attach_inferior (pid, &status, &signal) == -1)
+ if (attach_inferior (pid, &status, &signal, 0) == -1)
error ("Attaching not supported on this target");
/* Otherwise succeeded. */
next reply other threads:[~2008-06-27 23:11 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-27 23:26 Pedro Alves [this message]
2008-07-07 17:55 ` Daniel Jacobowitz
2008-07-07 23:52 ` Pedro Alves
2008-07-08 1:59 ` Pedro Alves
2008-07-11 14:13 ` Daniel Jacobowitz
2008-07-11 17:12 ` Pedro Alves
2008-07-11 17:37 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200806280011.12868.pedro@codesourcery.com \
--to=pedro@codesourcery.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox