From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3341 invoked by alias); 13 Nov 2012 17:23:03 -0000 Received: (qmail 3332 invoked by uid 22791); 13 Nov 2012 17:23:02 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO 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; Tue, 13 Nov 2012 17:22:55 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id EEA182E06D; Tue, 13 Nov 2012 12:22:54 -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 QpefpoVJwGhS; Tue, 13 Nov 2012 12:22:54 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id B1D6D1C7FCE; Tue, 13 Nov 2012 12:22:54 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 264D6C8076; Tue, 13 Nov 2012 09:22:37 -0800 (PST) Date: Tue, 13 Nov 2012 17:23:00 -0000 From: Joel Brobecker To: Mark Kettenis Cc: palves@redhat.com, gdb@sourceware.org Subject: Re: Time to expand "Program received signal" ? Message-ID: <20121113172237.GY4847@adacore.com> References: <50A13A4E.3020000@redhat.com> <20121113162530.GX4847@adacore.com> <201211131640.qADGeKhs021376@glazunov.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201211131640.qADGeKhs021376@glazunov.sibelius.xs4all.nl> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-11/txt/msg00021.txt.bz2 > I do find the strings somewhat long though. The lines wrap, and that > distracts people from the important bit, which is that a signal was > received. Are people really interested in the bit between. Isn't it > better to print just: > > Thread 2 received signal SIGUSR1, User defined signal 1. > > Folks can then use "info threads" to look at the details of the thread. Same here, and I'd be OK with the output you suggest. But the extra info might be useful if the thread disappeared before the user had a chance to do "info threads"... Perhaps this is a good situation where we should provide an option, so that the short output is used by default, but still allow a longer output when needed. -- Joel