This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch] testsuite/gdb.c++/local.exp: accept more nested types
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Mon, 27 May 2002 14:38:07 -0400
- Subject: Re: [patch] testsuite/gdb.c++/local.exp: accept more nested types
- References: <200205271827.g4RIRrb24032@duracef.shout.net>
On Mon, May 27, 2002 at 01:27:53PM -0500, Michael Elizabeth Chastain wrote:
> 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.
Let's go with a working philosophy of "both" then :)
> 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.
Indeed it is.
> 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?
I think that I (as C++ maintainer rather than testsuite maintainer)
need to figure out what the correct output is.
"InnerLocal::NestedInnerLocal nest1" is not actually valid C++ in
general, I don't believe; what if there is a class
InnerLocal::InnerLocal::NestedInnerLocal? I believe it will resolve to
that one instead of the correct one. This is also uglier; for std::
types there's going to be a lot of useless noise.
The ideal output, it seems to me, would be something like:
> ptype InnerLocal
> type = class InnerLocal {
> public:
> char ilc;
> int *ip;
> class NestedInnerLocal;
> NestedInnerLocal nest1;
>
> InnerLocal & operator=(InnerLocal const&);
> InnerLocal(InnerLocal const&);
> InnerLocal();
> int il_foo(unsigned char const&);
> }
Unambiguous, quite obviously correct. By this logic,
InnerLocal::NestedInnerLocal deserves a KFAIL comment for the moment,
since the code to do this is not yet present.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer