From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19575 invoked by alias); 17 Aug 2012 23:16:13 -0000 Received: (qmail 19567 invoked by uid 22791); 17 Aug 2012 23:16:12 -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; Fri, 17 Aug 2012 23:15:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 6505C1C6FC8; Fri, 17 Aug 2012 19:15:58 -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 LKYoT9LdzJYZ; Fri, 17 Aug 2012 19:15:58 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 344821C6FA7; Fri, 17 Aug 2012 19:15:58 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 6620814561A; Fri, 17 Aug 2012 16:15:54 -0700 (PDT) Date: Fri, 17 Aug 2012 23:16: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: <20120817231554.GF2798@adacore.com> References: <20120816152255.GA2836@adacore.com> <87zk5umwj3.fsf@fleche.redhat.com> <20120816224524.GC2798@adacore.com> <87628hmwbr.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87628hmwbr.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/msg00498.txt.bz2 > I think it would be reasonable, and maybe useful, if gdb could do > by-address searches for data symbols. That was a bigger change than I > wanted to make for the "set print symbol" series though. As mentioned on IRC, I just realize, now, the kind of project this is... So, I went with the other solution, which is to mark the minimal symbols from COFF/PE as size-less, and avoid the filtering in that case. Attached is a patch that does that. The patch was tested on x86-windows (using AdaCore's testsuite), as well as on x86_64-linux. But I am not proposing it's inclusion, for several reasons: 1. I strongly dislike this patch. It feels like an intrusive change to work around a heuristic that seems very fragile. I'd rather get rid of the heuristic and accept the false matches. I am wondering what would happen if we changed the code such that: If we find a function in the debugging info that matches our address, then use that instead of trying to see if the minimal symbol might be closer. When would that happen, anyway? 2. Applying the patch fixes the problem in the sense that we now get the name of the symbol next to the address. But on the other hand, it causes us to pick up some other (unrelated) symbols which were previously ignored by the heuristic. This is unexpected. After working on and off on this, I do not feel very confident that I will be able to tune the filtering to something that would satisfy me. So, rather than trying to do our best, I thought we might try to do the simplest (removing the filtering of zero-sized data symbols). Another option is for the FSF version of GDB to remain as it is, with its bias towards GNU/Linux, while we will change AdaCore's version to turn "set print symbol" to "off" by default... Thoughts? -- Joel