RFC: Formatting of type output

RFC: Formatting of type output

[Daniel Jacobowitz]

Right now, we get as much as we can from demangled names when we print
classes.  Fine for stabs, but for dwarf and (say) constructors, we don't
have a demangled name to use.

We can print the methods using just their types, from the debug info.  We
have plenty of information for doing that.

That means that, regrettably, they are formatted differently; it is closer
to the v2 demangler than to the v3 demangler, but different from both
(classes get prefixed by "class" even in C++, for example).

Does anything mechanical depend on the format of type output, besides our
testsuite?  Does anyone have any radically strong feelings about how it
should be formatted?  I believe that it should at least be consistent with
itself, and the only possible way to achieve that is to use the type
information at all times.  It'll require some cleanups to the involved code
(for instance, lookup_opaque_type currently kills qualifiers!  Patch later
this week when I have a moment) but will actually simplify the testsuite
quite a bit (since we will not have to cope with multiple demanglers, only
multiple class layouts).

Similarly, does anyone prefer to have vtbl and vbase pointers explicitly
printed?  It seems cleaner to me to suppress them, and perhaps offer another
way to print them explicitly.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Formatting of type output

[Eli Zaretskii]

> Date: Thu, 6 Dec 2001 12:02:05 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> 
> That means that, regrettably, they are formatted differently; it is closer
> to the v2 demangler than to the v3 demangler, but different from both
> (classes get prefixed by "class" even in C++, for example).

Could you please post a few examples how they are different?  It's
hard to reason about this without seeing some live examples; I guess
I don't know enough about this problem to figure this out myself.

> Does anything mechanical depend on the format of type output, besides our
> testsuite?

The documentation might include some examples which could need to be
changed.  Obviously, this is not a grave problem, but since you
asked...

Re: RFC: Formatting of type output

[Daniel Jacobowitz]

On Thu, Dec 06, 2001 at 10:42:22PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 6 Dec 2001 12:02:05 -0500
> > From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > That means that, regrettably, they are formatted differently; it is closer
> > to the v2 demangler than to the v3 demangler, but different from both
> > (classes get prefixed by "class" even in C++, for example).
> 
> Could you please post a few examples how they are different?  It's
> hard to reason about this without seeing some live examples; I guess
> I don't know enough about this problem to figure this out myself.

Well, here's an example.  v2/stabs:
type = class Class {
  private:
    int xxx;

  public:
    Class & operator=(Class const &);
    Class(Class const &);
    Class(void);
}

v3/stabs (after some patches not yet submitted to eliminate duplicate
constructors):
(gdb) ptype Class
type = class Class {
  private:
    int xxx;

  public:
    Class & operator=(Class const&);
    void Class(Class const&);
    void Class();
}


Notice "const &" becomes "const&" and "(void)" becomes "()".

For v3/dwarf, though:
(gdb) ptype Class
type = class Class {
  private:
    int xxx;

  public:
    Class & operator=(Class const&);
    Class(class Class &);
    Class(void);
}

See the "class Class &"?  That's because Class::Class does not have a
DW_AT_mips_linkage_name, so we use the method argument printer.  class Class
is opaque when the constructor is defined (a bug causes us to have lost
"const" here, I'll fix it).  operator= is still going through the v3
demangler.

Worse, do it a second time in the same GDB session:
type = class Class {
  private:
    int xxx;

  public:
    Class & operator=(Class const&);
    Class(Class &);
    Class(void);
}

And now it matches some combination of the other two.  I'm still trying
to figure out how to suppress "class" properly.

And what I'm proposing is to use the method argument printer all the
time.  If we do that, as it stands now:

(gdb) ptype Class
type = class Class {
  private:
    int xxx;

  public:
    Class & operator=(class Class &);
    Class(Class &);
    Class(void);
}

Now the "class Class" bug shows up earlier, and had the qualifiers not
been trampled we would have gained a space in front of the & for
operator=.

> > Does anything mechanical depend on the format of type output, besides our
> > testsuite?
> 
> The documentation might include some examples which could need to be
> changed.  Obviously, this is not a grave problem, but since you
> asked...

I'll keep it in mind.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: RFC: Formatting of type output

[Eli Zaretskii]

> Date: Thu, 6 Dec 2001 15:55:26 -0500
> From: Daniel Jacobowitz <drow@mvista.com>
> > 
> > Could you please post a few examples how they are different?  It's
> > hard to reason about this without seeing some live examples; I guess
> > I don't know enough about this problem to figure this out myself.
> 
> Well, here's an example [...]

Thanks, it's quite clear now.

FWIW, I don't think this change could annoy users, and the probability
of other programs depending on the precise format is quite low.

Re: RFC: Formatting of type output

[Michael Elizabeth Chastain]

Good morning Daniel,

> Does anything mechanical depend on the format of type output, besides our
> testsuite?

AFAIK, the white-space changes between v2 g++ and v3 g++ haven't
caused any external consumers of this information to break in such a way
that bug reports have reached the gnats database or the gdb mailing
lists.  So I would suspect "no".

> Does anyone have any radically strong feelings about how it
> should be formatted?

Basically no.

> Similarly, does anyone prefer to have vtbl and vbase pointers explicitly
> printed?

Are you talking about "ptype *Foo" or "print *pFoo" here?

At my day job, I use cygwin + gcc 2.95.3 + pthreads + gdb,
and the vtbl pointer is a quick indicator whether a pointer points
to a sane, live object.  That is a case of "print *pFoo".

> It seems cleaner to me to suppress them, and perhaps offer another
> way to print them explicitly.

That would be fine with me.

Michael C

Re: RFC: Formatting of type output

[Daniel Jacobowitz]

On Thu, Dec 06, 2001 at 11:39:10AM -0600, Michael Elizabeth Chastain wrote:
> Good morning Daniel,
> 
> > Does anything mechanical depend on the format of type output, besides our
> > testsuite?
> 
> AFAIK, the white-space changes between v2 g++ and v3 g++ haven't
> caused any external consumers of this information to break in such a way
> that bug reports have reached the gnats database or the gdb mailing
> lists.  So I would suspect "no".
> 
> > Does anyone have any radically strong feelings about how it
> > should be formatted?
> 
> Basically no.

I am going to attempt to print types without the use of the demangler,
then.  If I can get it to work adequately, I'll ask again.

> > Similarly, does anyone prefer to have vtbl and vbase pointers explicitly
> > printed?
> 
> Are you talking about "ptype *Foo" or "print *pFoo" here?
> 
> At my day job, I use cygwin + gcc 2.95.3 + pthreads + gdb,
> and the vtbl pointer is a quick indicator whether a pointer points
> to a sane, live object.  That is a case of "print *pFoo".

OK, that does seem useful.  Survey of facts and opinions:
  - are not part of the explicit data of the class
  - vary wildly depending on one's compiler.  2.95 has vbase pointers
only, 3.0 has vtbl pointers only.
  - are exceedingly useful to people debugging C++ support or Java
support, but not normally useful to people debugging user code.

I'm going to lean towards option (B) [suppressing them by default and
adding a set flag to show them] when I get around to this.  This is at
the bottom of my list though.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer