mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-11-27 03:54:41 +08:00
3405876ae7
Yao writes:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
GDB gets an internal error when it connects to GDBserver started with
'--disable-packet=qC'.
Sending packet: $QNonStop:0#8c...Packet received: OK
Sending packet: $?#3f...Packet received: T0505:00000000;04:00f0ffbf;08:b0c2e44c;thread:p4255.4255;core:1;
Sending packet: $Hc-1#09...Packet received: E01
Sending packet: $qC#b4...Packet received:
Sending packet: $qAttached:a410#bf...Packet received: E01
Packet qAttached (query-attached) is supported
warning: Remote failure reply: E01
Sending packet: $qOffsets#4b...Packet received:
../../../git/gdb/target.c:3248: internal-error: Can't determine the current address space of thread Thread 16981
When start remote, the call chain is as follows,
remote_start_remote
add_current_inferior_and_thread <--[1]
...
start_remote
wait_for_inferior
remote_wait_as
process_stop_reply
get_thread_arch_regcache <--[2]
remote_notice_new_inferior <--[3]
GDB sends packet "qC" in [1] and adds the thread/inferior if the remote
stubs understands "qC". In [2], GDB looks for the inferior to build a
regcache, and notices a new inferior in [3]. As we can see, GDB assumes
that the inferior can be found in [2]. Once the remote stub doesn't
support "qC", GDB can't look for the inferior in [2], and emits an
internal error.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Right after the initial connection, we query the target for its state,
with the ? packet. We store the resulting wait status / stop reply
aside, and query the target for the current thread, using qC, which
fails, so we fake a ptid for the target's thread. We then later,
after the initial setup, end up consuming that set-aside wait status,
parsing the T stop reply, which contains a "thread" "register" (which
was the thread the target would have replied to qC). We get into
trouble because the ptid in that stop reply doesn't match our faked up
ptid in the initial setup, although the target threads are the same...
So we had the T stop reply handy all along. We might as well extract
the thread's ptid from it, and avoid all the resulting issues.
qC is also used after vRun, in order to discover the new process'es
main thread. But, vRun's reply is also a wait status, just like
'?''s, which is quite convenient.
This means that if we have a "Txx thread: ptid" reply, then we don't
really need qC. The patch makes GDB look in the T reply first, and if
not found, try with qC. The packet handling seems to have been added
in gdb-4.18 (1999), and I see that in that same release, "Txx thread:
ptid" didn't exist yet, which probably explains why nobody though of
doing this before.
Regression tested against a gdbserver with qC disabled (and then
enabled), on x86_64 Fedora 17.
2013-01-25 Pedro Alves <palves@redhat.com>
* remote.c (stop_reply_extract_thread): New.
(add_current_inferior_and_thread): New parameter 'wait_status'.
Handle it.
(remote_start_remote): Pass wait status to
add_current_inferior_and_thread.
(extended_remote_run): Update comment.
(extended_remote_create_inferior_1): Pass wait status to
add_current_inferior_and_thread.
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| .cvsignore | ||
| .gitignore | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release | ||
| symlink-tree | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.