Re: RFA: implement ambiguous linespec proposal

[Jan Kratochvil <jan.kratochvil@redhat.com>]

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