From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19898 invoked by alias); 27 Apr 2007 11:27:35 -0000 Received: (qmail 19885 invoked by uid 22791); 27 Apr 2007 11:27:34 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 27 Apr 2007 12:27:32 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 0EAFD4B267; Fri, 27 Apr 2007 06:27:30 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id D08D74B262; Fri, 27 Apr 2007 06:27:27 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HhObn-00043M-1M; Fri, 27 Apr 2007 07:27:27 -0400 Date: Fri, 27 Apr 2007 13:27:00 -0000 From: Daniel Jacobowitz To: Markus Deuling Cc: GDB Patches Subject: Re: [rfc] Fix qC handling in gdbserver Message-ID: <20070427112726.GA15057@caradoc.them.org> Mail-Followup-To: Markus Deuling , GDB Patches References: <4631ADC8.6000603@de.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4631ADC8.6000603@de.ibm.com> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-04/txt/msg00356.txt.bz2 On Fri, Apr 27, 2007 at 10:01:12AM +0200, Markus Deuling wrote: > When looking at gdb.base/info-proc.exp I found a bug in remote target. > > GDB tries to get the initial pid after "target remote :". It does > that by set_thread (-1, 0), which results in a "Hc-1" packet. On gdbserver side > each Hc packet with '0' or '1' results in E01 packet as reply. Consider the comment you're deleting. There are remote stubs out there that work with versions of GDB older than thread support - I don't know if any of them are still in use, but I have no way to check, either. They will report thread information if they think GDB supports it, but not otherwise. I think the remote.c change is wrong. > Later on remote_current_thread (inferior_ptid); is called which always comes > back with MAGIC_NULL_PID. The reason for that is the missing support for 'qC' > packets in gdbserver. Manual says the reply for qC > is 'QC pid'. If no pid returns MAGIC_NULL_PID is taken. You should have read the paragraph just above :-) Like the descriptions of the other packets, each description here has a template showing the packet's overall syntax, followed by an explanation of the packet's meaning. We include spaces in some of the templates for clarity; these are not part of the packet's syntax. No GDB packet uses spaces to separate its components. So the reply doesn't have a space in it. But there's a bigger problem here. Look at this: > Because of that 'info proc' is broken directly after connecting to > gdbserver (it tries to access /proc/42000), thats why the testcase failes. GDB is opening /proc/pid on the _local_ machine. That's silly. gdbserver is usually running on a remote machine; it's only on the local machine during native testing. The testcase fails because info proc only works for native targets. We could fix this, since I was just discussing with Pedro some gdb protocol extensions for opening remote files... -- Daniel Jacobowitz CodeSourcery