Re: sunday project, gdb, 2003-09-26

Re: sunday project, gdb, 2003-09-26

[David Carlton]

On Sat, 27 Sep 2003 17:08:21 -0400, Michael Elizabeth Chastain
<mec@shout.net> said:

>     . gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42
>         PASS -> KFAIL

>         This is a regression in gdb.  The KFAIL is:

>           http://sources.redhat.com/gdb/bugs/826
>           variables in C++ namespaces have to be enclosed in quotes

>         This happened with gcc v3 -gstabs+.

GCC 3.3, specifically: I don't see this with 3.2, where it's always
been a KFAIL.  The debug info for stabs changed from 3.2 to 3.3, I
seem to recall.

>           # gdb.log
>           # gdb 2003-09-26 10:32:21 UTC
>           # gcc 3.3.1, binutils 2.14, -gstabs+
>           print (ClassWithEnum::PrivEnum) 42
>           A syntax error in expression, near `42'.
>           (gdb) KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826)
>           print ('ClassWithEnum::PrivEnum') 42
>           $26 = yellow
>           (gdb) PASS: gdb.cp/classes.exp: print ('ClassWithEnum::PrivEnum') 42

Yes.  Unfortunately, this is a problem with the parser: the lexer used
to (badly) handle nested types, and now the parser (badly) handles
nested types, and this is an area where the parser does a worse job
than the lexer used to.  Sigh.

>     . gdb.cp/local.exp: ptype InnerLocal::NestedInnerLocal
>         FAIL -> KFAIL
>           @ 113 115 117 119 121 123 125 127 129 131 133 135

>         This is a regression in gdb.  The KFAIL is:

>           http://sources.redhat.com/gdb/bugs/482
>           gdb.c++/local.exp: ptype InnerLocal::NestedInnerLocal

>         This happened with gcc v3 -gstabs+.

>         gdb.log excerpts:

>           # gdb.log
>           # gdb 2003-09-23 00:57:26 UTC
>           # gcc 3.3.1, binutils 2.14, -gstabs+
>           ptype InnerLocal::NestedInnerLocal
>           type = class InnerLocal::NestedInnerLocal {
>             public:
>               int nil;

>               InnerLocal::NestedInnerLocal & operator=(InnerLocal::NestedInnerLocal const&
>           );
>               NestedInnerLocal(InnerLocal::NestedInnerLocal const&);
>               NestedInnerLocal();
>               int nil_foo(int);
>           }
>           (gdb) FAIL: gdb.cp/local.exp: ptype InnerLocal::NestedInnerLocal

>           # gdb.log
>           # gdb 2003-09-26 10:32:21 UTC
>           # gcc 3.3.1, binutils 2.14, -gstabs+
>           ptype InnerLocal::NestedInnerLocal
>           There is no field named NestedInnerLocal
>           (gdb) KFAIL: gdb.cp/local.exp: ptype InnerLocal::NestedInnerLocal (PRMS: gdb/482)

Right: at first, I was wondering why you called this a regression,
given that it started out as a FAIL, but it really is the case that
the new output is worse.  (Is there anything wrong with the old
output?  It looks completely correct to me.)  Again, this is specific
to GCC 3.3, stabs; unlike the previous problem, however, this one will
get fixed once I get nested types working more fully.

David Carlton
carlton@kealia.com

Re: sunday project, gdb, 2003-09-26

[Michael Elizabeth Chastain]

mec>     . gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42
mec>         PASS -> KFAIL
mec>         This is a regression in gdb.  The KFAIL is:
mec>           http://sources.redhat.com/gdb/bugs/826
mec>           variables in C++ namespaces have to be enclosed in quotes
mec>         This happened with gcc v3 -gstabs+.

dc> GCC 3.3, specifically: I don't see this with 3.2, where it's always
dc> been a KFAIL.  The debug info for stabs changed from 3.2 to 3.3, I
dc> seem to recall.

Same here.  It didn't regress for me with gcc 3.2-7-rh because
it was already KFAIL'ing with that.

dc> Right: at first, I was wondering why you called this a regression,
dc> given that it started out as a FAIL, but it really is the case that
dc> the new output is worse.  (Is there anything wrong with the old
dc> output?  It looks completely correct to me.)

I think the old output is correct and it's just a matter of upgrading
the test script to handle the many variations of 'ptype' output.

Actually we could use some more infrastructure for doing that.
Writing four to six 500-character regexp's for each ptype is
very fragile.

I'll make a "6.0 versus HEAD" regression report a little while after
gdb 6.0 is released.

Michael C

Re: sunday project, gdb, 2003-09-26

[David Carlton]

On Mon, 29 Sep 2003 14:29:46 -0400, Michael Elizabeth Chastain <mec@shout.net> said:

> I think the old output is correct and it's just a matter of
> upgrading the test script to handle the many variations of 'ptype'
> output.

> Actually we could use some more infrastructure for doing that.
> Writing four to six 500-character regexp's for each ptype is very
> fragile.

Yeah, really.  Though I also don't think there should be four to six
of them: I don't like having regexps in there that we aren't seeing in
the wild.

David Carlton
carlton@kealia.com

Re: sunday project, gdb, 2003-09-26

[Daniel Jacobowitz]

On Mon, Sep 29, 2003 at 11:53:19AM -0700, David Carlton wrote:
> On Mon, 29 Sep 2003 14:29:46 -0400, Michael Elizabeth Chastain <mec@shout.net> said:
> 
> > I think the old output is correct and it's just a matter of
> > upgrading the test script to handle the many variations of 'ptype'
> > output.
> 
> > Actually we could use some more infrastructure for doing that.
> > Writing four to six 500-character regexp's for each ptype is very
> > fragile.
> 
> Yeah, really.  Though I also don't think there should be four to six
> of them: I don't like having regexps in there that we aren't seeing in
> the wild.

I posted a more readable way to do this, once.  I don't remember if I
ever finished working on it; I got distracted.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer