6dc54d9124
We have three methods to list the current remote thread list: 1. The qXfer:threads:read method (the preferred one nowadays), builds a remote thread list while parsing the XML, and then after the XML parsing is done, goes over the built list and adds threads GDB doesn't know about yet to GDB's list. 2. If the qXfer method isn't available, we fallback to using the qfThreadInfo/qsThreadInfo packets. When we do this, we adds threads to GDB's list immediately as we parse the qfThreadInfo/qsThreadInfo packet replies. 3. And then if the previous method isn't available either, we try the old deprecated qL packet. This path is already looking somewhat broken for not using remote_notice_new_inferior to add threads to GDB's list. This patch makes all variants work in two passes, like the qXfer method, and then makes all variants share the code path that adds threads to GDB's list. Tested on x86_64 Fedora 20 with native gdbserver. gdb/ 2014-10-15 Pedro Alves <palves@redhat.com> * remote.c (remote_get_threadlist, remote_threadlist_iterator): Add describing comment. Return -1 if the qL packet is not supported. (struct thread_item, thread_item_t): Move higher up in the file. Add comments. (struct threads_parsing_context): Move higher up in the file, add comments, and remote to ... (struct threads_listing_context): ... this. (remote_newthread_step): Don't add the thread to GDB's thread database here. Instead push it to the thread_listing_context list. (remote_find_new_threads): Rename to ... (remote_get_threads_with_ql): ... this. Add target_ops and targets_listing_context parameters. Pass down context. (start_thread): Adjust. (clear_threads_parsing_context): Rename to ... (clear_threads_listing_context): ... this. (remote_get_threads_with_qxfer): New, with parts salvaged from old remote_threads_info. (remote_get_threads_with_qthreadinfo): Ditto. (remote_threads_info): Reimplement.
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.