gdb.c++ failures

gdb.c++ failures

[Jason Merrill]

I've been looking at the various C++ debugging failures on
i686-pc-linux-gnu using dwarf2.  Here's my analysis:

  anon-union.exp: The C++ compiler is emitting an extra lexical block, so
   the breakpoint on the closing brace is treated as being outside the
   scope of the variable.  There are two issues here: The compiler output
   is wrong, and the testcase is relying on corner-case behavior that only
   works for the outermost block of a function.  Of course, I don't know
   how we could test for the compiler bug without doing this, so I suppose
   we might as well leave the testcase alone.

  classes.exp: dwarf2 doesn't provide mangled names for abstract
   constructors, and there is a difference of opinion between the
   demangler and c-typeprint.c as to whether the type should be written "A
   const &" or "const A &".  The demangler always puts the cv-qualifier
   after the type it affects, whereas gdb puts it in front whenever that
   would have the correct meaning.  Either one could be changed to match
   the other, or the testcase could be modified to accept either form.
   Thoughts?

   Also, gdb is including artificial arguments in the printed
   representation of the constructors for vB-vD.  The dwarf2 output
   indicates that they are artificial; gdb should not print them.  There
   doesn't seem to be a simple way to handle this in the current gdb data
   structures.

  cplusfuncs.exp: cp-demangle bug.  The code to handle demangling
   pointers-to-functions isn't complex enough.

  local.exp: The test tries to examine InnerLocal outside of its scope,
   which fails.  Doing a ptype while InnerLocal is in scope works fine.
   Meanwhile, ptype Local works outside of Local's scope; apparently being
   inside an additional block makes a difference.  This definitely seems
   like a gdb issue.

  method.exp: The 'print this' tests are failing because gdb is printing
   the types as, say, (A * const), and the test just wants (A *).  The
   former is correct, since 'this' is readonly.  Any objection to changing
   the test (and others affected) to allow the const?

  namespace.exp: gdb prints '\0', the testcase expects '\000'.  An obvious
   fix, which I will apply.

  templates.exp: the artificial args problem breaks destructor
   recognition.  Also, when asked to set a breakpoint on a constructor, gdb
   offers a menu of the different clones, which the testcase doesn't
   like; it seems correct to me.

   Also, the cv-qual placement issue breaks 'print Foo<volatile char *>::foo';
   it needs to be 'print "Foo<char volatile*>::foo"' to match the demangler
   output.  I take it the aCC demangler makes different choices?  I don't
   see any way to get around the dependence of template naming on the
   canonical format chosen by the demangler unless gdb learns to mangle
   names itself; perhaps the syntax of the test should vary with the compiler.

Jason

Re: gdb.c++ failures

[Daniel Jacobowitz]

On Thu, Jan 10, 2002 at 01:17:56PM +0000, Jason Merrill wrote:
> I've been looking at the various C++ debugging failures on
> i686-pc-linux-gnu using dwarf2.  Here's my analysis:

Already answered some of these, here's a few more...

>   classes.exp: dwarf2 doesn't provide mangled names for abstract
>    constructors, and there is a difference of opinion between the
>    demangler and c-typeprint.c as to whether the type should be written "A
>    const &" or "const A &".  The demangler always puts the cv-qualifier
>    after the type it affects, whereas gdb puts it in front whenever that
>    would have the correct meaning.  Either one could be changed to match
>    the other, or the testcase could be modified to accept either form.
>    Thoughts?

The demangler should be left alone and the type printer updated, as far
as I'm concerned - preferably to the GCC3 demangler style.  It
currently "mostly" matches the v2 style.  See the thread
"RFC: Formatting of type output" and particularly my last message in it
for examples.  That was... December 6th 2001.

>    Also, gdb is including artificial arguments in the printed
>    representation of the constructors for vB-vD.  The dwarf2 output
>    indicates that they are artificial; gdb should not print them.  There
>    doesn't seem to be a simple way to handle this in the current gdb data
>    structures.

What artificial arguments?  Or do you mean with GCC 2.95, where these
tests are XFAILd because of this?

>   cplusfuncs.exp: cp-demangle bug.  The code to handle demangling
>    pointers-to-functions isn't complex enough.

OK.  Would you mind marking the overly simplistic result as an XFAIL
(or do you anticipate it being fixed soon?)

>   local.exp: The test tries to examine InnerLocal outside of its scope,
>    which fails.  Doing a ptype while InnerLocal is in scope works fine.
>    Meanwhile, ptype Local works outside of Local's scope; apparently being
>    inside an additional block makes a difference.  This definitely seems
>    like a gdb issue.

I'll investigate this one later.

>   method.exp: The 'print this' tests are failing because gdb is printing
>    the types as, say, (A * const), and the test just wants (A *).  The
>    former is correct, since 'this' is readonly.  Any objection to changing
>    the test (and others affected) to allow the const?

The standard, or at least Stroustrop seems to disagree - this came up yesterday
on gdb-patches.  He claims it should be A *, but not changeable.  I
don't care.

>   namespace.exp: gdb prints '\0', the testcase expects '\000'.  An obvious
>    fix, which I will apply.

Oh, so that's what it was!  Thanks.

>   templates.exp: the artificial args problem breaks destructor
>    recognition.  Also, when asked to set a breakpoint on a constructor, gdb
>    offers a menu of the different clones, which the testcase doesn't
>    like; it seems correct to me.

I have:
break T5<int>::T5
the class T5<int> does not have any method named T5
Hint: try 'T5<int>::T5<TAB> or 'T5<int>::T5<ESC-?>
(Note leading single quote.)
(gdb) FAIL: gdb.c++/templates.exp: constructor breakpoint

for stabs, also.

Then with DWARF-2 I get a few type printing errors, and the constructor
menu.  I'll look at how that is done and try to make it work for stabs
too.  So please recognize the menu in the testsuite.  What about the
destructor test that fails?  And Garply is probably a cv-placement bug.

>    Also, the cv-qual placement issue breaks 'print Foo<volatile char *>::foo';
>    it needs to be 'print "Foo<char volatile*>::foo"' to match the demangler
>    output.  I take it the aCC demangler makes different choices?  I don't
>    see any way to get around the dependence of template naming on the
>    canonical format chosen by the demangler unless gdb learns to mangle
>    names itself; perhaps the syntax of the test should vary with the compiler.

Yes, it should.

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

Re: gdb.c++ failures

[Jason Merrill]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> On Thu, Jan 10, 2002 at 01:17:56PM +0000, Jason Merrill wrote:

>> classes.exp: dwarf2 doesn't provide mangled names for abstract
>> constructors, and there is a difference of opinion between the
>> demangler and c-typeprint.c as to whether the type should be written "A
>> const &" or "const A &".  The demangler always puts the cv-qualifier
>> after the type it affects, whereas gdb puts it in front whenever that
>> would have the correct meaning.  Either one could be changed to match
>> the other, or the testcase could be modified to accept either form.
>> Thoughts?

> The demangler should be left alone and the type printer updated, as far
> as I'm concerned - preferably to the GCC3 demangler style.

Works for me.

>> Also, gdb is including artificial arguments in the printed
>> representation of the constructors for vB-vD.  The dwarf2 output
>> indicates that they are artificial; gdb should not print them.  There
>> doesn't seem to be a simple way to handle this in the current gdb data
>> structures.

> What artificial arguments?  Or do you mean with GCC 2.95, where these
> tests are XFAILd because of this?

With dwarf2, the in-class abstract declaration of the constructor has
artificial parms for "in charge" and the VTT pointer.  The "in charge"
parameter is specialized away in both clones, and the VTT is is specialized
away in one of them, but both should be represented in the debug info,
ideally with DW_AT_const_value attributes where they have been specialized.

>> cplusfuncs.exp: cp-demangle bug.  The code to handle demangling
>> pointers-to-functions isn't complex enough.

> OK.  Would you mind marking the overly simplistic result as an XFAIL
> (or do you anticipate it being fixed soon?)

Will do.

>> method.exp: The 'print this' tests are failing because gdb is printing
>> the types as, say, (A * const), and the test just wants (A *).  The
>> former is correct, since 'this' is readonly.  Any objection to changing
>> the test (and others affected) to allow the const?

> The standard, or at least Stroustrop seems to disagree - this came up
> yesterday on gdb-patches.  He claims it should be A *, but not
> changeable.  I don't care.

Stroustrup is right; for whatever reason, the language specifies that
'this' is not an lvalue, so not only is it immutable, but you can't take
its address either.  I think it's more useful for the debugging information
to point at the hidden parameter used to pass the value of 'this' into the
function, for which A*const is a perfectly sensible type.

Jason

Re: gdb.c++ failures

[Michael Elizabeth Chastain]

Jason Merrill writes:

>  classes.exp: dwarf2 doesn't provide mangled names for abstract
>   constructors, and there is a difference of opinion between the
>   demangler and c-typeprint.c as to whether the type should be written "A
>   const &" or "const A &".  The demangler always puts the cv-qualifier
>   after the type it affects, whereas gdb puts it in front whenever that
>   would have the correct meaning.  Either one could be changed to match
>   the other, or the testcase could be modified to accept either form.
>   Thoughts?

I'm in favor of changing the test suite to accept either "A const &"
or "const A &".

>   method.exp: The 'print this' tests are failing because gdb is printing
>    the types as, say, (A * const), and the test just wants (A *).  The
>    former is correct, since 'this' is readonly.  Any objection to changing
>    the test (and others affected) to allow the const?

Fred Fish submitted a patch for this.  There is a second issue in the
patch about the type of "this" in const methods.  The type should be
"const A *", and I would be willing to accept "const A * const".
But gdb with stabs is printing just plain "A *".

On the question of accepting "A * const" as the type of "this",
I'm in favor of allowing that.

>  templates.exp:
>    Also, the cv-qual placement issue breaks 'print Foo<volatile char *>::foo';
>    it needs to be 'print "Foo<char volatile*>::foo"' to match the demangler
>    output.  I take it the aCC demangler makes different choices?  I don't
>    see any way to get around the dependence of template naming on the
>    canonical format chosen by the demangler unless gdb learns to mangle
>    names itself; perhaps the syntax of the test should vary with the compiler.

The test script could probe the demangler and then provide whatever
input gdb is using that day.  See gdb.c++/cplusfuncs.exp probe_demangler
for an example.

Michael C

Re: gdb.c++ failures

[Jason Merrill]

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

> Jason Merrill writes:
>> method.exp: The 'print this' tests are failing because gdb is printing
>> the types as, say, (A * const), and the test just wants (A *).  The
>> former is correct, since 'this' is readonly.  Any objection to changing
>> the test (and others affected) to allow the const?

> Fred Fish submitted a patch for this.

Quite so.  Fred, it looks good to me.

> There is a second issue in the patch about the type of "this" in const
> methods.  The type should be "const A *", and I would be willing to
> accept "const A * const".  But gdb with stabs is printing just plain "A
> *".

The stabs output from gcc ignores const and volatile.  There is even a
comment saying that "stabs does not distinguish const and volatile".
The method qualifiers are described, and gdb could do the work to apply
them to the type of 'this', but it's probably fine just to leave it as it
is.

>> templates.exp:
>> Also, the cv-qual placement issue breaks 'print Foo<volatile char *>::foo';
>> it needs to be 'print "Foo<char volatile*>::foo"' to match the demangler
>> output.  I take it the aCC demangler makes different choices?  I don't
>> see any way to get around the dependence of template naming on the
>> canonical format chosen by the demangler unless gdb learns to mangle
>> names itself; perhaps the syntax of the test should vary with the compiler.

> The test script could probe the demangler and then provide whatever
> input gdb is using that day.  See gdb.c++/cplusfuncs.exp probe_demangler
> for an example.

Good idea.  But is there no way to return a matched string in gdb_expect?
Testing for all possible permutations seems rather cumbersome.

Jason

Re: gdb.c++ failures

[Daniel Jacobowitz]

On Thu, Jan 10, 2002 at 07:21:18PM +0000, Jason Merrill wrote:
> >>>>> "Michael" == Michael Elizabeth Chastain <mec@shout.net> writes:
> 
> > Jason Merrill writes:
> >> method.exp: The 'print this' tests are failing because gdb is printing
> >> the types as, say, (A * const), and the test just wants (A *).  The
> >> former is correct, since 'this' is readonly.  Any objection to changing
> >> the test (and others affected) to allow the const?
> 
> > Fred Fish submitted a patch for this.
> 
> Quite so.  Fred, it looks good to me.

I agree.

> > There is a second issue in the patch about the type of "this" in const
> > methods.  The type should be "const A *", and I would be willing to
> > accept "const A * const".  But gdb with stabs is printing just plain "A
> > *".
> 
> The stabs output from gcc ignores const and volatile.  There is even a
> comment saying that "stabs does not distinguish const and volatile".
> The method qualifiers are described, and gdb could do the work to apply
> them to the type of 'this', but it's probably fine just to leave it as it
> is.

There are documented extensions to STABS to express both const and
volatile.  GDB supports them, and documents them - see info stabs. 
They're originally Sun extensions.

Could I persuade you to add them to GCC?  It would take you less time
than I.

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

Re: gdb.c++ failures

[Jason Merrill]

[-- Attachment #1: Type: text/plain, Size: 886 bytes --]

>>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:

> On Thu, Jan 10, 2002 at 07:21:18PM +0000, Jason Merrill wrote:
>> The stabs output from gcc ignores const and volatile.  There is even a
>> comment saying that "stabs does not distinguish const and volatile".
>> The method qualifiers are described, and gdb could do the work to apply
>> them to the type of 'this', but it's probably fine just to leave it as it
>> is.

> There are documented extensions to STABS to express both const and
> volatile.  GDB supports them, and documents them - see info stabs. 
> They're originally Sun extensions.

> Could I persuade you to add them to GCC?  It would take you less time
> than I.

Give this a whirl.  The output looks right to me, but gdb doesn't seem to
like it much.

2002-01-10  Jason Merrill  <jason@redhat.com>

	* dbxout.c (dbxout_type): Support const and volatile.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 2369 bytes --]

*** dbxout.c.~1~	Thu Jan 10 15:48:14 2002
--- dbxout.c	Thu Jan 10 21:22:53 2002
*************** dbxout_type (type, full)
*** 1050,1067 ****
      type = integer_type_node;
    else
      {
-       /* Try to find the "main variant" with the same name but not const
- 	 or volatile.  (Since stabs does not distinguish const and volatile,
- 	 there is no need to make them separate types.  But types with
- 	 different names are usefully distinguished.) */
- 	 
-       for (tem = TYPE_MAIN_VARIANT (type); tem; tem = TYPE_NEXT_VARIANT (tem))
- 	if (!TYPE_READONLY (tem) && !TYPE_VOLATILE (tem)
- 	    && TYPE_NAME (tem) == TYPE_NAME (type))
- 	  {
- 	    type = tem;
- 	    break;
- 	  }
        if (TYPE_NAME (type)
  	  && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
  	  && TYPE_DECL_SUPPRESS_DEBUG (TYPE_NAME (type)))
--- 1050,1055 ----
*************** dbxout_type (type, full)
*** 1157,1168 ****
  
    typevec[TYPE_SYMTAB_ADDRESS (type)].status = TYPE_DEFINED;
  
!   if (TYPE_NAME (type) && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
!       && DECL_ORIGINAL_TYPE (TYPE_NAME (type)))
!     { 
!       dbxout_type (DECL_ORIGINAL_TYPE (TYPE_NAME (type)), 0);
!       return;
!     }
  
    switch (TREE_CODE (type))
      {
--- 1145,1182 ----
  
    typevec[TYPE_SYMTAB_ADDRESS (type)].status = TYPE_DEFINED;
  
!   /* If this type is a variant of some other, hand off.  Types with
!      different names are usefully distinguished.  */
!   {
!     tree main_variant;
! 
!     if (TYPE_NAME (type) && TREE_CODE (TYPE_NAME (type)) == TYPE_DECL
! 	&& DECL_ORIGINAL_TYPE (TYPE_NAME (type)))
!       main_variant = TREE_TYPE (TYPE_NAME (type));
!     else
!       main_variant = TYPE_MAIN_VARIANT (type);
! 
!     if (TYPE_READONLY (type) > TYPE_READONLY (main_variant))
!       {
! 	putc ('k', asmfile);
! 	CHARS (1);
! 	dbxout_type (build_type_variant (type, 0, TYPE_VOLATILE (type)), 0);
! 	return;
!       }
!     else if (TYPE_VOLATILE (type) > TYPE_VOLATILE (main_variant))
!       {
! 	putc ('B', asmfile);
! 	CHARS (1);
! 	dbxout_type (build_type_variant (type, TYPE_READONLY (type), 0), 0);
! 	return;
!       }
!     else if (main_variant != TYPE_MAIN_VARIANT (type))
!       {
! 	dbxout_type (DECL_ORIGINAL_TYPE (TYPE_NAME (type)), 0);
! 	return;
!       }
!     /* else this isn't a cv-variant, so keep going.  */
!   }
  
    switch (TREE_CODE (type))
      {

Re: gdb.c++ failures

[Daniel Jacobowitz]

On Thu, Jan 10, 2002 at 09:24:44PM +0000, Jason Merrill wrote:
> >>>>> "Daniel" == Daniel Jacobowitz <drow@mvista.com> writes:
> 
> > On Thu, Jan 10, 2002 at 07:21:18PM +0000, Jason Merrill wrote:
> >> The stabs output from gcc ignores const and volatile.  There is even a
> >> comment saying that "stabs does not distinguish const and volatile".
> >> The method qualifiers are described, and gdb could do the work to apply
> >> them to the type of 'this', but it's probably fine just to leave it as it
> >> is.
> 
> > There are documented extensions to STABS to express both const and
> > volatile.  GDB supports them, and documents them - see info stabs. 
> > They're originally Sun extensions.
> 
> > Could I persuade you to add them to GCC?  It would take you less time
> > than I.
> 
> Give this a whirl.  The output looks right to me, but gdb doesn't seem to
> like it much.
> 
> 2002-01-10  Jason Merrill  <jason@redhat.com>
> 
> 	* dbxout.c (dbxout_type): Support const and volatile.

Of course it doesn't like it.  The stabs reader was missing two
important lines - see gdb-patches in a moment.

Only two const/volatile tests seem to fail after this patch.  They are:

int
qux1 (const char cc, const char /*&*/ccr, const char *ccp, char *const cpc)

int
qux2 (volatile unsigned char vuc, const volatile int cvi,
      volatile short /*&*/vsr, volatile long *vlp, float *volatile fpv,
      const volatile signed char *const volatile cvscpcv)

The const char cc, const char ccr, volatile unsigned char vuc, and volatile short
vsr all become 'int'.  'const volatile int cvi' comes through OK,
though, so it seems to be a problem of the subrange integer types. 
This is definitely GCC's fault and not GDB's - I checked the stabs by
hand.

I'd appreciate it if you'd commit this to GCC (although probably not to
the branch - since GDB 5.1 will object strenuously to them).

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