From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 521 invoked by alias); 25 Feb 2011 11:27:04 -0000 Received: (qmail 512 invoked by uid 22791); 25 Feb 2011 11:27:03 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=BAYES_00,TW_WT X-Spam-Check-By: sourceware.org Received: from mel.act-europe.fr (HELO mel.act-europe.fr) (194.98.77.210) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Feb 2011 11:26:58 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id E83A0CB01F7; Fri, 25 Feb 2011 12:26:55 +0100 (CET) Received: from mel.act-europe.fr ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cUZd2zG6iPpo; Fri, 25 Feb 2011 12:26:47 +0100 (CET) Received: from province.act-europe.fr (province.act-europe.fr [10.10.0.214]) by mel.act-europe.fr (Postfix) with ESMTP id 65C13CB024B; Fri, 25 Feb 2011 12:26:47 +0100 (CET) Received: by province.act-europe.fr (Postfix, from userid 560) id 5CF2E164808; Fri, 25 Feb 2011 12:26:47 +0100 (CET) Date: Fri, 25 Feb 2011 11:38:00 -0000 From: Jerome Guitton To: Eli Zaretskii Cc: brobecker@adacore.com, gdb-patches@sourceware.org Subject: Re: [PATCH 18/18] document the new VxWorks port Message-ID: <20110225112647.GA2254@adacore.com> References: <1298569763-18784-1-git-send-email-brobecker@adacore.com> <1298569763-18784-19-git-send-email-brobecker@adacore.com> <838vx5rzf8.fsf@gnu.org> <20110225102624.GB3211@adacore.com> <83ipw8qsfe.fsf@gnu.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <83ipw8qsfe.fsf@gnu.org> User-Agent: Mutt/1.5.17 (2007-11-01) 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: 2011-02/txt/msg00747.txt.bz2 Eli Zaretskii (eliz@gnu.org): > > > > +@kindex info wtx threads > > > > +@item info wtx threads > > > > > > Why a separate command? Isn't it possible to use "info threads"? > > > > "info threads" lists only the threads of the inferior, whereas > > "info wtx threads" lists all threads on target. > > Since there's no "inferior" on this target, is it so bad to show all > the threads? > > And what does "info threads" do on that target? It depends. In single-task mode, it displays only the thread being debugged. In multi-tasks mode, it displays the list of threads that have been created by a given kernel module. In both cases, "info threads" actually displays the threads that we are debugging (e.g. that are stopped when a breakpoint is reached); whereas "info wtx threads" displays any task running on kernel space (even those that that are not being debugged). > > The reason why it is not called, say, "info wtx processes", is a > > particularity of VxWorks: most applications actually run on kernel > > space, and share the same memory area. So they are really threads, not > > processes. > > That's fine, but then why not treat them as threads? Well, the thing is that we have a sort of emulation of "processes" (I'd guess that the concept of "thread group" would actually be a better fit here) in multi-tasks mode. So we need to have a distinction between the threads that are of interest for the debugger and the ones that just happen to run on the same memory space.