From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9086 invoked by alias); 17 Jun 2009 18:04:46 -0000 Received: (qmail 9078 invoked by uid 22791); 17 Jun 2009 18:04:45 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 17 Jun 2009 18:04:38 +0000 Received: (qmail 1362 invoked from network); 17 Jun 2009 18:04:35 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 17 Jun 2009 18:04:35 -0000 From: Pedro Alves To: gdb-patches@sourceware.org Subject: Re: [patch] gdbserver: qXfer multiprocess Date: Wed, 17 Jun 2009 18:04:00 -0000 User-Agent: KMail/1.9.10 Cc: Aleksandar Ristovski References: <200906170204.45325.pedro@codesourcery.com> <4A39258E.2000506@qnx.com> In-Reply-To: <4A39258E.2000506@qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200906171905.13381.pedro@codesourcery.com> 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: 2009-06/txt/msg00441.txt.bz2 On Wednesday 17 June 2009 18:19:10, Aleksandar Ristovski wrote: > Here is a patch that does what you described. Thanks. This is still not complete, though. You need to make sure that the "multi_process" flag stays turned off if the backend doesn't support MP, otherwise, things like remote-utils.c:write_ptid will still misbehave (gdb will realize the target doesn't support multi-process, but the remote target will be replying with multi-process packets, how odd would that be?!). That flag is currently bound to GDB's multi-process support, because current gdbserver is assuming all backends support mp. /* Record if GDB knows about multiprocess support. */ if (strcmp (p, "multiprocess+") == 0) multi_process = 1; To see this in action, you can connect with "target extended-remote :foo"/"set debug remote 1", and make sure that the packets flowing in both directions don't use multi-process thread id extensions (e.g., 'p1.1' vs '1'). -- Pedro Alves