Re: Another "ptype B" validity question

Re: Another "ptype B" validity question

[Michael Elizabeth Chastain]

Daniel J writes:
> It is _not_ acceptable.  I thought I'd gotten most of these but
> obviously I've missed some.  Please do file a bug.

Okay, I will do that.

With gdb HEAD and binutils 2.13.1 and stabs+:

  gcc 3.2.1   48 FAIL, 81 XFAIL
  gcc HEAD   114 FAIL, 80 XFAIL

It's going to be a couple of bug reports.  :(

gcc HEAD with dwarf-2 is fine compared to gcc 3.2.1 with dwarf-2.

Here is a good table for you:

  http://www.shout.net/~mec/sunday/2002-11-25/difference/compare-by-gcc-17.html

Michael C

Re: Another "ptype B" validity question

[Michael Elizabeth Chastain]

mec> . If gdb does print the "A;" member, is that acceptable or not?
mec>   Note that this is a slightly different question!

drow> It is _not_ acceptable.  I thought I'd gotten most of these but
drow> obviously I've missed some.  Please do file a bug.

Gotcha, pr gdb/869, ""ptype class B" fails with 3.3-ish gcc, stabs.".  I
attached a tarball with the test executable in it (among other things) so you
can get right to the nitty gritty.

Michael C

Another "ptype B" validity question

[Michael Elizabeth Chastain]

I'm seeing some new output from the "ptype" command when I use a new
version of the compiler.

Here are some gdb.log excerpts.

The first excerpt is fine:

  # gdb HEAD, gcc 3.2.1, binutils 2.13.1, stabs+
  ptype class B
  type = class B : public A {
    public:
      int b;
      int x;
  
      B & operator=(B const&);
      B(B const&);
      B();
  }
  (gdb) PASS: gdb.c++/classes.exp: ptype class B

The second excerpt raises an issue:

  # gdb HEAD, gcc HEAD, binutils 2.13.1, stabs+
  ptype class B
  type = class B : public A {
    public:
      A;
      int b;
      int x;
  
      B & operator=(B const&);
      B(B const&);
      B();
  }
  (gdb) FAIL: gdb.c++/classes.exp: ptype class B

Note the "A" line.  I suppose this is gdb's way of showing the
base class as a data member.

My questions are:

. What should gdb print for this ptype operation?

. If gdb does print the "A;" member, is that acceptable or not?
  Note that this is a slightly different question!

. More generally, what is the long term future of stabs+?

I really need an answer for #2 so that I can decide whether to change
the test script or brandish the FAIL in a bug report.

My view is that the test suite should be liberal about what it accepts
in the output of "ptype" as long as it is somehow correct and does not
mislead human users.  In this case, I think that most C++ programmers
would understand the nature of the "A;" line, so I would like to
change classes.exp to accept it.

Michael C

Re: Another "ptype B" validity question

[Gabriel Dos Reis]

Michael Elizabeth Chastain <mec@shout.net> writes:


[...]

|   # gdb HEAD, gcc HEAD, binutils 2.13.1, stabs+
|   ptype class B
|   type = class B : public A {
|     public:
|       A;

[...]

| My questions are:
| 
| . What should gdb print for this ptype operation?
| 
| . If gdb does print the "A;" member, is that acceptable or not?
|   Note that this is a slightly different question!

I think the line 

    class B : public A 

saying that B inherits from A is self-explanatory and there is no need
to display A as a member-declaration -- it is not, and that is confusing.


[...]

|                       In this case, I think that most C++ programmers
| would understand the nature of the "A;" line,

Well, I find it very confusing -- it is too close to nested-type
declaration. 

-- Gaby

Re: Another "ptype B" validity question

[Daniel Jacobowitz]

On Tue, Dec 03, 2002 at 09:56:58AM -0600, Michael Elizabeth Chastain wrote:
> I'm seeing some new output from the "ptype" command when I use a new
> version of the compiler.
> 
> Here are some gdb.log excerpts.
> 
> The first excerpt is fine:
> 
>   # gdb HEAD, gcc 3.2.1, binutils 2.13.1, stabs+
>   ptype class B
>   type = class B : public A {
>     public:
>       int b;
>       int x;
>   
>       B & operator=(B const&);
>       B(B const&);
>       B();
>   }
>   (gdb) PASS: gdb.c++/classes.exp: ptype class B
> 
> The second excerpt raises an issue:
> 
>   # gdb HEAD, gcc HEAD, binutils 2.13.1, stabs+
>   ptype class B
>   type = class B : public A {
>     public:
>       A;
>       int b;
>       int x;
>   
>       B & operator=(B const&);
>       B(B const&);
>       B();
>   }
>   (gdb) FAIL: gdb.c++/classes.exp: ptype class B
> 
> Note the "A" line.  I suppose this is gdb's way of showing the
> base class as a data member.
> 
> My questions are:
> 
> . What should gdb print for this ptype operation?

Ideally?  Without checking the source, I'd guess:

type = class B : public A {
  public:
    int b;
    int x;
}

We do not have enough information to figure out that the constructors
are artificial in stabs+, though.  Lord, I've tried and tried - I can
produce exactly the same debug output with artificial and explicit
constructors.  I had a couple of heuristics for this but they are never
terribly reliable.

> . If gdb does print the "A;" member, is that acceptable or not?
>   Note that this is a slightly different question!

It is _not_ acceptable.  I thought I'd gotten most of these but
obviously I've missed some.  Please do file a bug.

> . More generally, what is the long term future of stabs+?

Rotting in a dark pit somewhere?

Seriously, we need to either accept limited C++ support with stabs, or
make GCC emit Sun DBX style stabs which have enough information.  And
make GDB understand them since it doesn't right now.  Since GCC 3.2 has
changed the default to DWARF-2 this is a looooong way down my priority
list!

> I really need an answer for #2 so that I can decide whether to change
> the test script or brandish the FAIL in a bug report.
> 
> My view is that the test suite should be liberal about what it accepts
> in the output of "ptype" as long as it is somehow correct and does not
> mislead human users.  In this case, I think that most C++ programmers
> would understand the nature of the "A;" line, so I would like to
> change classes.exp to accept it.

Please don't.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer