This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: gdb linux testing regressions (compared to 7/24)
Jimmy Guo <guo@cup.hp.com> writes:
> FYI:
>
> Latest gdb source has a test regression of 200+ as compared to the 7/24
> tree, on i686-pc-linux-gnu. For example, gdb.base/break.exp:
> ...
> print marker2(99)
>
> read_register_bytes: Couldn't update register 16.
>
> (gdb) FAIL: gdb.base/break.exp: hit breakpoint on called function
> ...
>
> Regression info is provided below ...
>
...
> gdb.c++/classes.exp
> | F |: base class param->a
> | F |: base class param->x
> | F |: inherited class param->a
> | F |: inherited class param->x
> | F |: base class param.a
> | F |: base class param.x
> | F |: inherited class param.a
> | F |: inherited class param.x
>
Known.
But it's actually
FAIL: base class (¶m)->a
FAIL: base class (¶m)->x
FAIL: inherited class (¶m)->a
FAIL: inherited class (¶m)->x
FAIL: continue to enums2
now.
> gdb.c++/demangle.exp
> | F |: gnu:
>__thunk_64__0RL__list__Q29CosNaming20_proxy_NamingContextUlRPt25_CORBA_Unbounded_Sequence1ZQ29CosNaming7BindingRPQ29CosNaming15BindingIterator
I claim this can't be unambiguously demangled, as it has more than one
legal demangling.
This will have to be marked XFAIL.
I'll add more tests that break the demangler before i fixed it, to
show this is worth it (I know it's worth it. Before, customers
complained about things not being able to be demangled. Now, they
don't).
>
> gdb.c++/namespace.exp
> | F |: print 'AAA::xyzq'('x')
> | F |: print 'BBB::CCC::xyzq'('x')
>
Unreproducable.
I get "FAIL: info func xyzq" instead, but it's clearly not failing.
info func xyzq^M
All functions matching regular expression "xyzq":^M
^M
File ./gdb.c++/namespace.cc:^M
int AAA::A_xyzq(int);^M
char AAA::xyzq(char);^M
int BBB::B_xyzq(int);^M
char BBB::CCC::xyzq(char);^M
char BBB::Class::xyzq(char);^M
char BBB::xyzq(char);^M
All of these properly match xyzq.
> gdb.c++/templates.exp
> | F |: print t5i.value()
I can only reproduce under stabs
It looks like a name gets demangled properly the firsttime, when we
print it the second, it's garbage.
This tells me it's a method stub problem, and i'm on it.
Under dwarf2 i get no failures at all.
--Dan