From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22655 invoked by alias); 16 Nov 2009 10:17:58 -0000 Received: (qmail 22643 invoked by uid 22791); 16 Nov 2009 10:17:57 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 16 Nov 2009 10:16:50 +0000 Received: (qmail 11115 invoked from network); 16 Nov 2009 10:16:48 -0000 Received: from unknown (HELO wind.localnet) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 16 Nov 2009 10:16:48 -0000 From: Vladimir Prus To: Marc Khouzam Subject: Re: [MI] Extending -list-thread-groups --available to show cores Date: Mon, 16 Nov 2009 17:55:00 -0000 User-Agent: KMail/1.12.2 (Linux/2.6.31-14-generic-pae; KDE/4.3.2; i686; ; ) Cc: "'gdb@sources.redhat.com'" References: <200911081804.31988.vladimir@codesourcery.com> <200911161128.38397.vladimir@codesourcery.com> In-Reply-To: <200911161128.38397.vladimir@codesourcery.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200911161316.46419.vladimir@codesourcery.com> 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-11/txt/msg00154.txt.bz2 On Monday 16 November 2009 11:28:38 Vladimir Prus wrote: > 1. Different output from the above commands. It's backward compatible, and > not > hard to support. Also, if you're asking for details on 20 processes, and a couple > of them have disappeared, you have a place to report that processes are no longer. > > 2. Multiple thread= if details for multiple processes are requested. As I say above, > this is somewhat unclean. > > 3. Always output groups=[], even for 1-process case. > > In fact, option (3) does not seem too bad. Does any frontend available in the > wild make use of thread groups? And 'support 7.0 and later' issue is easily solved > by accepting both groups=[] and threads= in output of 1-process -list-thread-groups. > In fact, we can even put text in the manual to suggest this. While updating the spec, I have realized that (1) is actually not a problem. We already have different outputs for different -list-thread-groups. If you pass nothing, you get groups=[] output. If you pass a single group, you get threads= output. Then, it seems not so bad to make '-list-thread-groups g1 g2' output be the same as '-list-thread-groups' -- the latter uses groups=[] on top-level exactly because it has to report several groups. - Volodya