This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: C++/Java regressions
- From: mec dot gnu at mindspring dot com (Michael Elizabeth Chastain)
- To: drow at mvista dot com, mec dot gnu at mindspring dot com
- Cc: carlton at kealia dot com, gdb at sources dot redhat dot com, ian at wasabisystems dot com
- Date: Tue, 25 Nov 2003 10:33:05 -0500 (EST)
- Subject: Re: C++/Java regressions
drow> The former, since ths has been the documented interface to the
drow> demangler forever.
Sounds good to me.
drow> I believe the GNU v2 demangler supported it.
Yes it does.
drow> But I thought we did everywhere - where aren't we that this caused
drow> a problem?
I don't know what's causing the problem with the java tests.
print_frame in stack.c is part of the problem with gdb.cp/method.exp.
It's intentionally omitting DMGL_PARAMS. But actually it's just
a precursor for some other code that I haven't find yet.
With v2, when DMGL_PARAMS is not set, the arguments don't get printed,
and the "const" modifier doesn't get printed either.
Breakpoint 3, A::bar (this=0xbffff770, arg=15) at ...
With the old v3 demangler, the args get printed even though we
didn't ask for them:
Breakpoint 3, A::bar(int) const (this=...)
With the new v3 demangler, the args do not get printed, but the
"const" attribute is printed:
Breakpoint 3, A::bar const (this=...)
So actually the old demangler was broken, and the new demangler is
doing what we ask it to do. Now we have to think about what we really
want to see.
What is the correct output when a breakpoint is taken on
"A::bar(int) const" ?
(This particular test accepts either "A::bar" or "A::bar(int) const",
but not "A::bar const". That's why the FAIL popped up. Just another
bit of ad-hoc matching. After we decide what should be printed,
I can change the test).
Michael C