From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13468 invoked by alias); 24 Jun 2010 20:01:12 -0000 Received: (qmail 13380 invoked by uid 22791); 24 Jun 2010 20:01:10 -0000 X-SWARE-Spam-Status: No, hits=-5.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_BJ,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; Thu, 24 Jun 2010 20:01:00 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5OK0kWl007396 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Jun 2010 16:00:46 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o5OK0jZs027907; Thu, 24 Jun 2010 16:00:46 -0400 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 o5OK0irl010511; Thu, 24 Jun 2010 16:00:45 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id 65127888255; Thu, 24 Jun 2010 14:00:44 -0600 (MDT) From: Tom Tromey To: Doug Evans Cc: Keith Seitz , gdb-patches@sourceware.org, Pedro Alves Subject: Re: [RFA] c++/11734 References: <4C20103B.1080906@redhat.com> <201006221045.23196.pedro@codesourcery.com> <4C20DA1A.10301@redhat.com> Reply-To: tromey@redhat.com Date: Thu, 24 Jun 2010 20:01:00 -0000 In-Reply-To: (Doug Evans's message of "Wed, 23 Jun 2010 19:25:08 -0700") 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-06/txt/msg00555.txt.bz2 >>>>> "Doug" == Doug Evans writes: Doug> There may be more going on here though, I don't understand why Doug> decode_line_1 has *both* is_quoted and is_quote_enclosed (is there Doug> some cleanup that can be done here, or is there a technical reason Doug> to handle " different from '?). Based on my last foray into decode_line_1, I would say that it is likely that nobody knows the answer to this question. That code is seriously twisted and horrible. E.g., see PR 8883, or 11289, or 11614. I think we should plan to rewrite it -- Keith was talking about this a while ago... maybe he got scared off ;-) In the short run I am inclined to approve anything that fixes problems and doesn't regress. Doug> There are several callers and rather than changing all of them to Doug> strip method overloading of the name to search for, it seems Doug> reasonable to handle it in lookup_partial_symbol. One thing I would like to know is the exact semantics required of these lookup functions. That is, if the implementation of one or more quick functions is expected to strip the "(" stuff, then that ought to be documented in symfile.h. Doug> IWBN if psymtabs didn't require that complexity and *only* recorded Doug> the un-overloaded name. And then...? I suppose we could expand all psymtabs with a matching name, then let the symtab code be intelligent about picking out matches. It is pretty easy to add a pre-expansion call like this. This is what the index branch does -- it records names only, not symbol types, so before a name lookup is done it reads all the CUs that define the name, regardless of how it is defined there. FWIW, Sami is working on an approach like this for template functions. I think it is a promising approach, though I'm concerned about how we will handle different instantiations of the same unadorned name appearing in multiple objfiles. Doug> AIUI, what you're doing here is having the lookup "fail" if an Doug> overloaded-name is found, so that a subsequent search in the full Doug> symtab will be done and, having expanded the psymtab here, that search Doug> will succeed. However psymtabs are searched *after* symtabs. This Doug> patch works because it turns out that we will later do a search in the Doug> full symtab, but that's more by accident than design: Do you know what exact code path is taken here? I think what is intended to happen is that a call to a quick function may result in symtab expansion. Then the caller is supposed to look in this symtab for the answer. E.g., lookup_symbol_aux_quick does this. Doug> This situation is not well solved by our normal psymtabs->symtabs lazy Doug> expansion design. Doug> I don't have a specific proposal for a better fix at the moment. Doug> Comments? We should probably also plan on a symtab overhaul. Right now gdb's behavior is dependent on the order of psymtab expansion. This can result in weird results for users, even for pretty ordinary code. I don't think this is very good. Pre-expansion would fix this, though maybe at a cost; and maybe that alone would introduce new problems as well. Also I think we have some bugs that we could fix if symtab lookups returned all the symbols for a given name -- not just the first one matching. Perhaps we would even need to extend this to work across objfiles; I imagine we have plenty of lurking bugs in this scenario. We may also want to consider the multi-inferior objfile reuse problem when doing this. Perhaps a new symtab API could return relocated symbols or something along those lines. I'm very interested to learn about other cases where we have trouble. Tom