Re: RFA: implement ambiguous linespec proposal

Tom Tromey
2011-11-03T20:49:14Z

Jan> -PASS: gdb.cp/ovsrch.exp: break outer::foo if (a == 3)
Jan> +FAIL: gdb.cp/ovsrch.exp: break outer::foo if (a == 3)
Jan> -PASS: gdb.cp/ovsrch.exp: break inner::foo if (a == 3)
Jan> +FAIL: gdb.cp/ovsrch.exp: break inner::foo if (a == 3)

Tom> I don't like how this test assumes that gdb will do a namespace search
Tom> for a symbol when decoding linespecs. That just seems wrong to me.
Tom> But, we've shipped it for a while, so I think we'll have to cope.

I am not sure we can make this work sanely. I'm tempted to declare
these tests invalid and remove them.

Consider this program:

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. And, I still think that makes a lot of sense for
expressions. But for linespecs I am not convinced, as I think they are
different in nature: they may be re-parsed in many different contexts
and they may apply across objfiles and program spaces. Also, for C++ at
least, I think "work like the compiler" will have more awful
implications: ADL, template stuff, ... I would rather just require the
user to type what they mean.

Tom