This is the mail archive of the
mailing list for the GDB project.
Re: RFA: implement ambiguous linespec proposal
- From: Tom Tromey <tromey at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org
- Date: Tue, 01 Nov 2011 14:57:47 -0600
- Subject: Re: RFA: implement ambiguous linespec proposal
- References: <firstname.lastname@example.org> <20111028221459.GA28467@host1.jankratochvil.net>
>>>>> "Jan" == Jan Kratochvil <email@example.com> writes:
Jan> -PASS: gdb.base/step-line.exp: break f1
Jan> +FAIL: gdb.base/step-line.exp: break f1
This fails because there is a (data) symbol named 'f1' in libm.
I think 'break' and friends will have to pass in a flag meaning "only
look for text symbols".
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)
I don't like how this test assumes that gdb will do a namespace search
for a symbol when decoding linespecs. That just seems wrong to me.
But, we've shipped it for a while, so I think we'll have to cope.
I think I will need a new language method to handle this properly.
The test itself is bogus since it makes an assumption about which
overload 'inner::foo' will match. I think it should match all of them,
and in one of them there is no symbol named 'a'.
Jan> Just on Fedora 16 x86_64 with -m32:
Jan> -PASS: gdb.threads/thread_check.exp: breakpoint at tf
Jan> +FAIL: gdb.threads/thread_check.exp: breakpoint at tf
Similar to step-line, 'tf' is a .bss symbol in libc.