This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: implement ambiguous linespec proposal
- From: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- To: Tom Tromey <tromey at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Fri, 4 Nov 2011 08:45:43 +0100
- Subject: Re: RFA: implement ambiguous linespec proposal
- References: <m3obx184iu.fsf@fleche.redhat.com> <20111028221459.GA28467@host1.jankratochvil.net> <m3ty6nzhkk.fsf@fleche.redhat.com> <m38vnxrkxz.fsf@fleche.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