Re: RFA: implement ambiguous linespec proposal

Jan Kratochvil
2011-11-04T07:46:10Z

On Thu, 03 Nov 2011 21:48:56 +0100, Tom Tromey wrote:
[...]
> namespace N1 {
> int m() { return 23; }
> };
>
> namespace N2 {
> int m() { return 23; }
> };
>
> int main()
> {
> using namespace N1;
> using namespace N2;
> return 0;
> }
>
> I think this is valid (g++ accepts it).
>
> What should gdb do if we are stopped in 'main' and the user types 'break m'?
>
>
> Doing namespace searches is a problem if they yield an ambiguous result
> because either:
>
> 1. There is no canonical name that can be put into the breakpoint for
> resetting, or
>
> 2. The breakpoint would have to also capture the current block for
> re-setting, which opens a whole new set of problems.
>
>
> I understand that the rationale here is for gdb to work like the
> compiler does.

Compiler says:
.C:13:6: error: call of overloaded ‘m()’ is ambiguous
.C:13:6: note: candidates are:
.C:6:7: note: int N2::m()
.C:2:7: note: int N1::m()

and I think GDB should also say the same output as error.

It is questionable what it should do on re-set if it becomes ambigous. One
can store the available namespaces as strings with the breakpoint (instead of
storing pointer to the block - where the block may disappear).

I understand it is not feasible to throw an error if ambiguity happens later
on a breakpoint re-set, so a multi-location breakpoint is probably OK.

Which brings a question whether the multi-location breakpoint should not be
placed there already when creating the breakpoint (instead of the suggested
error). As GDB already ignores `static' for variables in other files and
already ignores even C++ access specifiers it cannot work exactly like the
compiler anyway.

> I would rather just require the user to type what they mean.

It breaks that GDB should be able to parse what the source says.

Thanks,
Jan