From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19432 invoked by alias); 11 Feb 2010 19:50:46 -0000 Received: (qmail 19423 invoked by uid 22791); 11 Feb 2010 19:50:45 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 11 Feb 2010 19:50:41 +0000 Received: from int-mx05.intmail.prod.int.phx2.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o1BJnwf3013766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Feb 2010 14:49:59 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o1BJnvM0000435; Thu, 11 Feb 2010 14:49:57 -0500 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o1BJnuxT028201; Thu, 11 Feb 2010 14:49:57 -0500 Received: by opsy.redhat.com (Postfix, from userid 500) id 15AEB378261; Thu, 11 Feb 2010 12:49:56 -0700 (MST) From: Tom Tromey To: Joel Brobecker Cc: Chris Moller , gdb-patches@sourceware.org Subject: Re: pr 11067 patch References: <4B737180.4050802@redhat.com> <20100211092950.GC2907@adacore.com> Reply-To: tromey@redhat.com Date: Thu, 11 Feb 2010 19:50:00 -0000 In-Reply-To: <20100211092950.GC2907@adacore.com> (Joel Brobecker's message of "Thu, 11 Feb 2010 13:29:50 +0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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-02/txt/msg00299.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: >> Provides a little more info on enums for simple 'p ' cases; >> keeps the old format for complex cases like structs and arrays: Joel> I feel really bad about this, and I really apologize - I am just Joel> only suddenly wondering why this is considered a good idea, was Joel> that discussed? A little bit on the archer list, but not really directly. Joel> 1. If I print 'e', GDB prints 'Val1' and that's OK. Joel> 2. If I print 'Val1', GDB prints also prints 'Val1' and he says Joel> that, instead, GDB should print its numerical value. Joel> I disagree on (2) because, if he wanted the numerical value, he should Joel> have told GDB. For instance: Joel> (gdb) p GREEN Joel> $1 = GREEN Joel> (gdb) p /d GREEN Joel> $2 = 1 Joel> If people still think that this suggestion is a good one, I looked at Joel> the patch (the least I could do)... I asked Chris to work on this because I run into this with some frequency. I often will print some enum-typed value and get a symbolic answer. Then I have to type another command to get the numeric answer. It seems mildly friendlier to simply always print it, at least at the top level. (In stack traces and in structures it may wind up being too verbose, hence that decision.) Differentiating cases 1 and 2 above is not really practical because the evaluation and printing code are kept separate. If you disagree strongly, then we could just close the PR and drop it, I suppose. I am not very intent on this, I just thought it would be a nice, if minor, enhancement. I didn't see a real downside. Joel> Can you place each statement on their own line? I am guessing that Joel> GNU indent will fix that anyway, and I also think that this is harder Joel> to read. I think we've abandoned any hope of using GNU indent. Thanks for reviewing this. Tom