This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch] testsuite/gdb.c++/local.exp: accept more nested types


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]