Re: [RFA] c++/11734

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Doug" == Doug Evans <dje@google.com> 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