[prev in list] [next in list] [prev in thread] [next in thread]
List: gdb-cvs
Subject: gdb and binutils branch master updated. 7d1a114c44db3d7055afe48868f939ba95a64b7b
From: palves () sourceware ! org
Date: 2014-10-28 12:07:22
Message-ID: 20141028120722.23976.qmail () sourceware ! org
[Download RAW message or body]
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "gdb and binutils".
The branch, master has been updated
via 7d1a114c44db3d7055afe48868f939ba95a64b7b (commit)
from 708d7d0d11f0f2d776171979aa3479e8e12a38a0 (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=7d1a114c44db3d7055afe48868f939ba95a64b7b
commit 7d1a114c44db3d7055afe48868f939ba95a64b7b
Author: Pedro Alves <palves@redhat.com>
Date: Tue Oct 28 11:35:10 2014 +0000
Workaround remote targets that report an empty list to qfThreadInfo
In https://sourceware.org/ml/gdb-patches/2014-10/msg00652.html, Sandra
shows a target that was broken by the recent update_thread_list
optimization:
(gdb) target remote qa8-centos32-cs:10514
...
(gdb) continue
Continuing.
Cannot execute this command without a live selected thread.
(gdb)
The error means that the current thread is in "exited" state when the
continue command is processed. The root of the problem was found
here:
> Sending packet: $Hg0#df...Packet received:
...
> Sending packet: $?#3f...Packet received: S00
> Sending packet: $qfThreadInfo#bb...Packet received: l
> Sending packet: $Hc-1#09...Packet received:
> Sending packet: $qC#b4...Packet received: unset
This target doesn't really support threads (no thread indication in
stop reply packets; no support for qC), but then supports
qfThreadInfo, and returns an empty thread list to GDB.
See https://sourceware.org/ml/gdb-patches/2014-10/msg00665.html for
why the target does that.
As remote_update_thread_list deletes threads from GDB's list that are
not found in the thread list that the target reports, the result is
that GDB deletes the "fake" main thread that GDB added itself. (As
that thread is currently selected, it is marked "exited" instead of
being deleted straight away.)
This commit avoids deleting the main thread in this scenario.
gdb/
2014-10-27 Pedro Alves <palves@redhat.com>
* remote.c (remote_thread_alive): New, factored out from ...
(remote_thread_alive): ... this.
(remote_update_thread_list): Bail out before deleting threads if
the target returned an empty list, and, the current thread has a
magic/fake ptid.
-----------------------------------------------------------------------
Summary of changes:
gdb/ChangeLog | 8 ++++++++
gdb/remote.c | 35 ++++++++++++++++++++++++++++++++---
2 files changed, 40 insertions(+), 3 deletions(-)
hooks/post-receive
--
gdb and binutils
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic