This is the mail archive of the
mailing list for the GDB project.
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
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
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
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.