From: mec.gnu@mindspring.com (Michael Elizabeth Chastain)
To: drow@mvista.com, mec.gnu@mindspring.com
Cc: carlton@kealia.com, gdb@sources.redhat.com, ian@wasabisystems.com
Subject: Re: C++/Java regressions
Date: Tue, 25 Nov 2003 15:33:00 -0000 [thread overview]
Message-ID: <20031125153305.788C04B409@berman.michael-chastain.com> (raw)
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
next reply other threads:[~2003-11-25 15:33 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-11-25 15:33 Michael Elizabeth Chastain [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-11-26 22:48 Michael Elizabeth Chastain
2003-11-26 21:44 Michael Elizabeth Chastain
2003-11-26 22:21 ` Ian Lance Taylor
2003-11-26 22:28 ` Daniel Jacobowitz
2003-11-26 22:34 ` Ian Lance Taylor
2003-11-26 21:18 Michael Elizabeth Chastain
2003-11-26 21:33 ` Ian Lance Taylor
2003-11-25 17:06 Michael Elizabeth Chastain
2003-11-25 17:14 ` David Carlton
2003-11-25 17:59 ` Daniel Jacobowitz
2003-11-25 14:49 Michael Elizabeth Chastain
2003-11-25 15:06 ` Daniel Jacobowitz
2003-11-25 4:44 Michael Elizabeth Chastain
2003-11-25 17:54 ` Ian Lance Taylor
2003-11-25 1:37 David Carlton
2003-11-25 3:58 ` Ian Lance Taylor
2003-11-26 4:04 ` Ian Lance Taylor
2003-11-26 15:32 ` Daniel Jacobowitz
2003-11-26 21:05 ` Ian Lance Taylor
2003-11-26 21:11 ` David Carlton
2003-11-26 21:12 ` Daniel Jacobowitz
2003-11-26 21:32 ` Ian Lance Taylor
2003-12-01 16:45 ` Daniel Jacobowitz
2003-11-30 2:57 ` Jim Blandy
2003-11-30 3:12 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20031125153305.788C04B409@berman.michael-chastain.com \
--to=mec.gnu@mindspring.com \
--cc=carlton@kealia.com \
--cc=drow@mvista.com \
--cc=gdb@sources.redhat.com \
--cc=ian@wasabisystems.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox