From: Michael Elizabeth Chastain <mec@shout.net>
To: drow@mvista.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [patch] testsuite/gdb.c++/local.exp: accept more nested types
Date: Mon, 27 May 2002 11:38:00 -0000 [thread overview]
Message-ID: <200205271827.g4RIRrb24032@duracef.shout.net> (raw)
Daniel Jacobowitz writes:
mec> This patch updates local.exp to track an improvement in gdb.
mec> In a configuration with gcc HEAD -gstabs+, gdb prints nested types
mec> as "InnerLocal::NestedInnerLocal" instead of just "NestedInnerLocal".
dj> It's an improvement in GCC's debug output, I believe; I seem to recall
dj> Kevin posting a patch for this to gcc-patches recently.
I don't think it's a change in gcc because gcc does not show this change
with gdb 5.2 or gdb gdb_5_2-branch. It happens only with gdb HEAD.
Although there have been changes in gcc this week in this area. Perhaps
it really is a gcc change, and gdb HEAD is the only gdb looking at the
area of the change.
dj> Is it really? It seems to me that we should strip off the name of the
dj> enclosing class from nested types. This becomes more of an issue with
dj> the DWARF-2 type printing I'm experimenting with.
This is a philosophical issue. Let's explore it.
gdb's output is:
# target=native, host=i686-pc-linux-gnu%rh-7.2, gdb=HEAD%20020526
# gcc=HEAD%20020526, binutils=HEAD%20020526, glibc=VENDOR,
# goption=-gstabs+
ptype InnerLocal
type = class InnerLocal {
public:
char ilc;
int *ip;
InnerLocal::NestedInnerLocal nest1;
InnerLocal & operator=(InnerLocal const&);
InnerLocal(InnerLocal const&);
InnerLocal();
int il_foo(unsigned char const&);
}
gdb presents me with this output. What result should I assign to it?
I think this is a PASS. I think that the output is clear to humans.
The construct "InnerLocal::NestedInnerLocal nest1" is also valid C++;
if you add back in the definition of NestedInnerLocal, then it will
compile.
I also accept "NestedInnerLocal nest1;" as a PASS.
Philosophically, I'm not interested in the "one true output". I look
at what gdb actually prints in each configuration, and then classify
these into PASS and FAIL. This is especially true for "ptype" output,
where the output depends on the compiler and debug format.
What do you think?
Michael C
next reply other threads:[~2002-05-27 18:27 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-05-27 11:38 Michael Elizabeth Chastain [this message]
2002-05-27 11:41 ` Daniel Jacobowitz
-- strict thread matches above, loose matches on Subject: below --
2002-05-27 13:09 Michael Elizabeth Chastain
2002-05-27 11:07 Michael Elizabeth Chastain
2002-05-27 11: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=200205271827.g4RIRrb24032@duracef.shout.net \
--to=mec@shout.net \
--cc=drow@mvista.com \
--cc=gdb-patches@sources.redhat.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