From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11413 invoked by alias); 8 Mar 2010 18:41:37 -0000 Received: (qmail 11404 invoked by uid 22791); 8 Mar 2010 18:41:37 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 08 Mar 2010 18:41:33 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 524F82BAB3F; Mon, 8 Mar 2010 13:41:31 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id yBkjH253mkXo; Mon, 8 Mar 2010 13:41:31 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id C6BAA2BAB3D; Mon, 8 Mar 2010 13:41:30 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 277C7F5894; Mon, 8 Mar 2010 22:41:12 +0400 (RET) Date: Mon, 08 Mar 2010 18:41:00 -0000 From: Joel Brobecker To: Kevin Buettner Cc: gdb-patches@sourceware.org Subject: Re: [commit/RFA] Avoid switch to invalid ptid during Ada task switch. Message-ID: <20100308184112.GJ3081@adacore.com> References: <1267975529-28959-1-git-send-email-brobecker@adacore.com> <20100308062637.3a03cd51@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100308062637.3a03cd51@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-03/txt/msg00322.txt.bz2 > I think that the wording that you added is fine, though I find it > confusing to see that there's a new thread, [New Thread 10250], but > that GDB is unable to switch to it. I think it might be less > confusing if the [New Thread...] message did not appear at all. I'm > guessing though that suppressing that message would not be easy, and > probably not worthwhile, especially for a case that's not supposed to > happen. Thanks for the feedback. About that new-thread message, I don't think it's avoidable. On some targets, we "discover" threads only on demand. What I mean by that is that the kernel does not send a notification of some kind when a new thread is created or destroyed. It's GDB that has to actively go look for new threads (target_ops to_find_new_threads). GDB does not do this update systematically every time we stop - it would be very expensive. So GDB it only does so when it needs to access that thread list. For instance, when the user requests the list of threads. Using the same example I used in my first message, here is the output I get if I use "info threads" rather than try to perform a task switch: (gdb) info threads [New Thread 7598] 3 Thread 7598 0x00007f865d88e5a9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 * 2 Thread 7599 task_switch.break_me () at task_switch.adb:44 1 Thread 7592 0x00007f865d88e5a9 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 And if I only now try to perform the task switch, I only get the new error message: (gdb) task 1 Unable to compute thread ID for task 1. Cannot switch to this task. (no new-thread notification). -- Joel