This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA] c++/11734


On 06/23/2010 07:25 PM, Doug Evans wrote:
I think the change to linespec.c should be a separate patch.

I shall try to isolate the linespec.c change and a test.


And I think decode_compound shouldn't be modifying what saved_arg
points to.

Ah, that's right. Gdb passes these things around like they were going out of style... That is easy enough to avoid, though.


I guess this raises the follow-on question, does something like "'c::foo()' const" work? I suspect not (with or without my patch). I will write some new tests for this and see what I can do.

So it seems like a better way to go is to
teach locate_first_half about all quote characters.

I'll investigate that avenue, which is, I gather, to treat all single and double quotes "equivalently." [i.e, probably not exactly identically: "XXX" == 'XXX'; "XXX' and 'XXX" illegal; not even going to try "X'Y'Z" -- I'd be better off rewriting linespec.c than tackle some of these problems!]


There may be more
going on here though, I don't understand why decode_line_1 has *both*
is_quoted and is_quote_enclosed (is there some cleanup that can be
done here, or is there a technical reason to handle " different from
'?).

At one time, I convinced myself that I understood the difference between is_quoted and is_quote_enclosed... I'll have to spend some time to remind/convince myself again.


For the lookup_partial_symbol patch:
>
In the case of simple_name != NULL, do we need to call
SYMBOL_MATCHES_SEARCH_NAME twice?
IWBN if psymtabs didn't require that complexity and *only* recorded
the un-overloaded name.

If I understand your argument correctly, yes, it seems that if we know that SYMBOL_MATCHES_SEARCH_NAME uses strcmp_iw, then we do not need to call it twice, since strcmp_iw ("foo", "foo()") will not match. But this seems just as hacky as relying on a subsequent symtab search to find the right symbol. What happens if SYMBOL_MATCHES_SEARCH_NAME is changed to use something other than strcmp_iw. [I know that is highly improbable in the near future.]


Could we set name to simple_name when simple_name is created, and then
have only one call to SYMBOL_MATCHES_SEARCH_NAME?

I've reversed the logic in this (check simple name first), short-circuiting the second call (again, since we know that it can never match because SYMBOL_MATCHES_SEARCH_NAME boils down to strcmp_iw, for which the second argument cannot contain parenthesis unless the first argument does). This currently shows no regressions, either.


However psymtabs are searched *after* symtabs.

That's right. psymtabs are searched later:


This patch works because it turns out that we will later do a search in the
full symtab, but that's more by accident than design:

Yup. That was what I meant by "hacky."


This situation is not well solved by our normal psymtabs->symtabs lazy
expansion design.
I don't have a specific proposal for a better fix at the moment.

I don't either, but I'm going to try to address your concerns and your other suggestion to immediately search for the symbol in the symtab.


Thank you for reviewing this.
Keith


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]