From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7678 invoked by alias); 20 Aug 2012 17:48:41 -0000 Received: (qmail 7665 invoked by uid 22791); 20 Aug 2012 17:48:38 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_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; Mon, 20 Aug 2012 17:48:22 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7KHmKN4013128 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 20 Aug 2012 13:48:20 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q7KHmJns025952 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 20 Aug 2012 13:48:20 -0400 From: Tom Tromey To: Joel Brobecker Cc: gdb-patches@sourceware.org Subject: Re: RFC: printing pointers to global (data) variable on Windows... References: <20120816152255.GA2836@adacore.com> <87zk5umwj3.fsf@fleche.redhat.com> <20120816224524.GC2798@adacore.com> <87628hmwbr.fsf@fleche.redhat.com> <20120817231554.GF2798@adacore.com> Date: Mon, 20 Aug 2012 17:48:00 -0000 In-Reply-To: <20120817231554.GF2798@adacore.com> (Joel Brobecker's message of "Fri, 17 Aug 2012 16:15:54 -0700") Message-ID: <87r4r1h2u4.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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/msg00552.txt.bz2 >>>>> "Joel" == Joel Brobecker writes: Joel> 1. I strongly dislike this patch. It feels like an intrusive change Joel> to work around a heuristic that seems very fragile. I'd rather Joel> get rid of the heuristic and accept the false matches. I accept that, but there's another way of looking at it. It is just a fact that some minimal symbol readers can supply size information, while others cannot. Right now, this difference is obscured in the gdb internals -- if you have a minimal symbol you can't determine whether the size is "zero but valid" or "invalid". So, supplying the flag makes gdb better model reality. In this sense it is an improvement. Now, whether it is a *useful* improvement... :) Joel> I am wondering what would happen if we changed the code such that: Joel> If we find a function in the debugging info that matches our Joel> address, then use that instead of trying to see if the minimal Joel> symbol might be closer. When would that happen, anyway? Yeah, I don't know. Joel> After working on and off on this, I do not feel very confident that Joel> I will be able to tune the filtering to something that would satisfy Joel> me. So, rather than trying to do our best, I thought we might try Joel> to do the simplest (removing the filtering of zero-sized data symbols). 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. It is, I think, a symbol that doesn't name a whole object, but rather just some marker in the assembly. The code for the filter is actually somewhat goofier, allowing text symbols through. That just corresponds to gdb's historical behavior; I am not sure whether or not it is reasonable behavior, but it didn't make sense to change it in the context of that patch. At least, the intent is to have it provide the historical behavior; in the past I think build_address_symbolic was only called for functions. 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? Tom