From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19341 invoked by alias); 2 Jul 2008 11:52:38 -0000 Received: (qmail 19330 invoked by uid 22791); 2 Jul 2008 11:52:37 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jul 2008 11:52:19 +0000 Received: (qmail 25488 invoked from network); 2 Jul 2008 11:52:17 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 2 Jul 2008 11:52:17 -0000 From: Pedro Alves To: gdb@sourceware.org, Dmitry Smirnov Subject: Re: How to catch GDB crash Date: Wed, 02 Jul 2008 11:52:00 -0000 User-Agent: KMail/1.9.9 References: In-Reply-To: MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_vv2aImlTzAa2lEJ" Message-Id: <200807021252.15748.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00012.txt.bz2 --Boundary-00=_vv2aImlTzAa2lEJ Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 1554 Hi Dmitry, thanks for taking the time to investigate deeper. A Wednesday 02 July 2008 12:05:28, Dmitry Smirnov wrote: > Hi, > > Regarding the problem of -exec-run, I've suspended its investigation: I've > found that 6.8.50.20080630 just didn't respond "running" and this seems > reasonable. So, perhaps, previous version is misbehaving so causing Eclipse > behave wrong way. Though, it is not clear why gdbServer CDT debugger also > fails. Just postponed... > I don't know what to say about this failure. The command was already failing before, but it was outputting a spurious "^running". Why is eclipse even trying to run a process in with "target remote", I don't know. > I've found another Eclipse CDT debugger variant that can run as I wish. > And here I have a problem that I was reported to Pedro earlier: Eclipse is > unable to disassemble the code, show variables, etc. > > I've noticed that GDB respond to "info threads" contains an error message. > Below is the stack dump of this situation. I'm suspecting this respond > prevents Eclipse from doing right. > What is that "T1"? I don't know. It looks like a bug in the stub/simulator. Do you have a way to activate remote protocol debugging? "set debug remote 1" is the GDB command to use. The stub embedded in the simulator you're using doesn't seem to support any other thread related packets, and I would expect it to reply "" to this packet too. In the mean time, I think the attached patch (untested other than building it) is sensible. Could you give it a try? -- Pedro Alves --Boundary-00=_vv2aImlTzAa2lEJ Content-Type: text/x-diff; charset="koi8-r"; name="dont_query_internal_threads.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="dont_query_internal_threads.diff" Content-length: 956 2008-07-02 Pedro Alves * remote.c (remote_threads_extra_info): Don't query the remote server about the
thread. --- gdb/remote.c | 6 ++++++ 1 file changed, 6 insertions(+) Index: src/gdb/remote.c =================================================================== --- src.orig/gdb/remote.c 2008-07-02 12:39:07.000000000 +0100 +++ src/gdb/remote.c 2008-07-02 12:50:31.000000000 +0100 @@ -2042,6 +2042,12 @@ remote_threads_extra_info (struct thread internal_error (__FILE__, __LINE__, _("remote_threads_extra_info")); + if (ptid_equal (tp->ptid, magic_null_ptid) + || (ptid_get_pid (tp->ptid) != 0 && ptid_get_tid (tp->ptid) == 0)) + /* This is the main thread which was added by GDB. The remote + doesn't know about it, so don't query about it. */ + return NULL; + if (use_threadextra_query) { xsnprintf (rs->buf, get_remote_packet_size (), "qThreadExtraInfo,%lx", --Boundary-00=_vv2aImlTzAa2lEJ--