From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9918 invoked by alias); 25 Jun 2012 15:06:14 -0000 Received: (qmail 9910 invoked by uid 22791); 25 Jun 2012 15:06:13 -0000 X-SWARE-Spam-Status: No, hits=-6.5 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,SPF_HELO_PASS,T_RP_MATCHES_RCVD 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, 25 Jun 2012 15:05:52 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q5PF5o0t030579 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 25 Jun 2012 11:05:50 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q5PF5nPT016219 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 25 Jun 2012 11:05:50 -0400 From: Tom Tromey To: Cary Coutant Cc: Doug Evans , gdb-patches@sourceware.org Subject: Re: [RFA] Add global/static and symbol kind indicator to .gdb_index References: <20120619074931.6F0B41E136F@ruffy2.mtv.corp.google.com> <87txy3f7wr.fsf@fleche.redhat.com> <87y5nfdpq7.fsf@fleche.redhat.com> Date: Mon, 25 Jun 2012 15:06:00 -0000 In-Reply-To: (Cary Coutant's message of "Fri, 22 Jun 2012 14:20:22 -0700") Message-ID: <87r4t3ctyq.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-06/txt/msg00773.txt.bz2 >>>>> "Cary" == Cary Coutant writes: Cary> If the right thing to do is to have only one CU, how do I decide Cary> what kinds of names get this treatment? I don't know of a trivial rule. You can dig around and look at struct partial_symbol and struct general_symbol_info and deduce most of the rules. But this is really hairy. The index is really tied to gdb's occasionally questionable internals. This is one of its major disadvantages. You could probably come up with a conservative approximation to the real rule, that would work pretty well. I'd imagine it is most important for types; and also easier there since types don't have a location. Cary> (For example, some arbitrary Cary> type "struct foo" might actually be a different type, and you'd want Cary> multiple index entries.) You would think so, but no, because gdb will only ever expand one of those in response to an index-based lookup. The index is really only used in the case where some symbol cannot be found in the current context (or where there isn't really a current context in the sense of some fully-read CU). Tom