From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30418 invoked by alias); 3 Apr 2009 22:03:27 -0000 Received: (qmail 30408 invoked by uid 22791); 3 Apr 2009 22:03:26 -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; Fri, 03 Apr 2009 22:03:22 +0000 Received: (qmail 3091 invoked from network); 3 Apr 2009 22:03:20 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 3 Apr 2009 22:03:20 -0000 From: Pedro Alves To: gdb@sourceware.org Subject: Re: About "process 42000" Date: Sat, 04 Apr 2009 06:52:00 -0000 User-Agent: KMail/1.9.10 Cc: Shrinand Javadekar , Michael Snyder References: <200904031915.47714.pedro@codesourcery.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200904032303.37476.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: 2009-04/txt/msg00044.txt.bz2 On Friday 03 April 2009 22:46:25, Shrinand Javadekar wrote: > Ooops... I think this was because of my mistake. I have my own gdb > server. In the list of processes being returned for "info threads", I > was returning a process with pid 0. Gdb would then give this a process > id of 42000. Ah, I see. both -1 and 0 have special meaning in the remote protocol. Thread '0' will more or less work since selecting thread 0 (Hg0 or Hc0) 0 means "select any thread", and 0 would be an "any thread". You're better off avoiding doing that. > Sending packet: $qsThreadInfo#c8...Ack > Packet received: m0 > [New process 42000] > > Gdb then shows "process 42000" in the output. However, from here on, > it does not try to find out if this process is alive. It will always > show "process 42000" in the output. So every "info threads" command > after this one will have "process 42000" in the output. This is GDB assuming that the main thread is always alive (src/gdb/remote.c:remote_thread_alive), for targets that don't support qC or reporting the thread id in the T stop reply packet, after a vAttach... You will indeed stop seeing this happen when you make your target not report a thread id of 0. -- Pedro Alves