RFA: implement ambiguous linespec proposal
Tom Tromey
tromey@redhat.com
Thu Nov 3 20:49:00 GMT 2011
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
More information about the Gdb-patches
mailing list