From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16185 invoked by alias); 21 Aug 2012 15:36:53 -0000 Received: (qmail 16091 invoked by uid 22791); 21 Aug 2012 15:36:52 -0000 X-SWARE-Spam-Status: No, hits=-1.9 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, 21 Aug 2012 15:36:39 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 319281C7556; Tue, 21 Aug 2012 11:36:38 -0400 (EDT) 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 GHWL4AakWl3M; Tue, 21 Aug 2012 11:36:38 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id F41C11C7534; Tue, 21 Aug 2012 11:36:37 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id E686214561A; Tue, 21 Aug 2012 08:36:27 -0700 (PDT) Date: Tue, 21 Aug 2012 15:36:00 -0000 From: Joel Brobecker To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: RFC: printing pointers to global (data) variable on Windows... Message-ID: <20120821153627.GS2798@adacore.com> References: <20120816152255.GA2836@adacore.com> <87zk5umwj3.fsf@fleche.redhat.com> <20120816224524.GC2798@adacore.com> <87628hmwbr.fsf@fleche.redhat.com> <20120817231554.GF2798@adacore.com> <87r4r1h2u4.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87r4r1h2u4.fsf@fleche.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: 2012-08/txt/msg00572.txt.bz2 > So, supplying the flag makes gdb better model reality. In this sense it > is an improvement. Now, whether it is a *useful* improvement... :) This is true. > It seems to me that the filter is correct: if you are on a platform > where minimal symbol sizes are valid, and you see a symbol of size zero, > it does not make sense to print such a symbol. OK, that makes sense. We might even want to go a little further and exclude symbols if our address is past the end of the symbol. For instance, if we have a symbol "bla" at 0x1000, and its size is 4 bytes, and we're calling our routine with 0x1008, I am not sure it makes much sense saying 0x1008 is . But maybe it does? > Joel> Another option is for the FSF version of GDB to remain as it is, > Joel> with its bias towards GNU/Linux, while we will change AdaCore's > Joel> version to turn "set print symbol" to "off" by default... > > If you disable "set print symbol", how would that differ from leaving > the filter in place? I was just sweeping the problem under the rug... Not making it the default is my way of telling the users that the feature is not completely prime-time; and so the minor quirks you can get on some of the systems are to be expected. It would also save me a ton of time not having to tweak the expected output in the testsuite, but that's a minor detail. I haven't decided about what to do with the default, but regardless, I tend to think that you're right about flagging size-less symbols. It will effectively disable the filter on COFF platforms, allowing some symbols that would otherwise be filtered, but I guess that's better than ignoring too many symbols... I'll try working on that today. Thanks, Tom. -- Joel