From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6474 invoked by alias); 5 Jul 2008 03:15:41 -0000 Received: (qmail 6451 invoked by uid 22791); 5 Jul 2008 03:15:38 -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; Sat, 05 Jul 2008 03:14:44 +0000 Received: (qmail 2935 invoked from network); 5 Jul 2008 03:14:42 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 5 Jul 2008 03:14:42 -0000 From: Pedro Alves To: gdb@sourceware.org, Dmitry Smirnov Subject: Re: How to catch GDB crash Date: Sat, 05 Jul 2008 03:15:00 -0000 User-Agent: KMail/1.9.9 References: <200807021252.15748.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807050414.43765.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/msg00033.txt.bz2 A Wednesday 02 July 2008 13:50:00, Dmitry Smirnov wrote: > I'm wondering why GDB is trying to get ThreadExtraInfo if stub has > responded that it does not support threads? BTW, I didn't see this "Reply > contains invalid hex digit 84" in older GDBs. That's because versions of GDB until about a week ago didn't register a main thread/task in the internal thread table if the target didn't report thread support. Now we're always registering a main thread even in that case. When you do "info threads", GDB queries the target side for more info on each of the registered threads. Since previously there was 0 threads registered, there were 0 qThreadExtraInfo queries performed. Now, there's a thread, so GDB core does 1 query. But, since this thread was added internally by GDB behind the remote side's back, we need to bar it just before letting the query out to the remote side. That's what this new patch does. > Does stub HAVE to support it? No, it's optional. But if the stub doesn't support it, it MUST reply an empty response (an empty C string, as for all unsupported packets). Failing to do that is what looks like a bug in the simulator. > P.S. I'll test your patch a little bit later and come back with results. Thanks! -- Pedro Alves l