From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22467 invoked by alias); 17 Mar 2004 18:55:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22459 invoked from network); 17 Mar 2004 18:55:38 -0000 Received: from unknown (HELO granger.mail.mindspring.net) (207.69.200.148) by sources.redhat.com with SMTP; 17 Mar 2004 18:55:38 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B3gCI-0001qR-00; Wed, 17 Mar 2004 13:55:23 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 87D7A4B104; Wed, 17 Mar 2004 13:55:28 -0500 (EST) To: carlton@kealia.com, mec.gnu@mindspring.com Subject: Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0 Cc: eliz@gnu.org, gdb-patches@sources.redhat.com Message-Id: <20040317185528.87D7A4B104@berman.michael-chastain.com> Date: Wed, 17 Mar 2004 18:55:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-03.o/txt/msg00394.txt mec> gdb/826: variables in C++ namespaces have to be enclosed in quotes mec> mec> When referring to a variable in C++ code that is inside a mec> namespace, you have to put it inside single quotes. dc> This is only true in rare circumstances, and it was always true in dc> versions before 6.1! So whatever it might be, it's not a regression. dc> (Hmm: I should probably close that bug report, since it should largely dc> be fixed by now.) This test case works with gdb 6.0 and it does not work with gdb gdb-6_1-branch. # gdb 6.0, gcc 3.3.3, -gstabs+ (gdb) print (ClassWithEnum::PrivEnum) 42 $26 = yellow PASS: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 # gdb gdb-6_1-branch, gcc 3.3.3, -gstabs+ (gdb) print (ClassWithEnum::PrivEnum) 42 A syntax error in expression, near `42'. KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826) Actually, the word 'variable' is funny, because ClassWithEnum::PrivEnum is a type, not a variable. But that's what the test script calls this problem. And it's definitely a regression. mec> gdb/931: GDB could be more generous when reading types C++ mec> templates on input mec> mec> When the user types a template, GDB frequently requires the type to be mec> typed in a certain way (e.g. "const char*" as opposed to "const char *" mec> or "char const *" or "char const*"). dc> This also has always been the case. It is the case that GDB's dc> preferred form has, in some circumstances changed from 6.0 to 6.1, but dc> GDB has always had a preferred form. Yes, I know. If a user has a gdb script which pre-sets a lot of breakpoints with "break 'Foo::foo", they have to change their script with each release of gdb. That's why I consider this a regression, because it breaks user scripts. The regression in the test scripts is just an indicator that user scripts will break too. But it was worth some more text here. mec> gdb/1512: no canonical way to output names of C++ types mec> mec> We currently don't have any canonical way to output names of C++ types. mec> E.g. "const char *" versus "char const *"; more subtleties aries when mec> dealing with templates. dc> Again, this has always been the case - this isn't a regression. This is more subtle. gdb has scripted input, but how many people have scripted output for gdb? That is, when gdb changes its output from this: (gdb) ptype fvpchar type = class Foo { to this: (gdb) ptype fvpchar type = class Foo { Is that going to break a contract we have with the users? Are there any users that are going to be affected, such as front ends that are parsing or gdb's output? I'm inclined to say "yes", because we do consider the second form a KFAIL. If both output forms are okay then I think the test script should test them both. But I'm more flexible on this than I am on *input* form, where anything that used to be accepted in 6.0 and is no longer accepted in 6.1 is likely to break a user script. Michael C From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22467 invoked by alias); 17 Mar 2004 18:55:39 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 22459 invoked from network); 17 Mar 2004 18:55:38 -0000 Received: from unknown (HELO granger.mail.mindspring.net) (207.69.200.148) by sources.redhat.com with SMTP; 17 Mar 2004 18:55:38 -0000 Received: from user-119a90a.biz.mindspring.com ([66.149.36.10] helo=berman.michael-chastain.com) by granger.mail.mindspring.net with esmtp (Exim 3.33 #1) id 1B3gCI-0001qR-00; Wed, 17 Mar 2004 13:55:23 -0500 Received: by berman.michael-chastain.com (Postfix, from userid 502) id 87D7A4B104; Wed, 17 Mar 2004 13:55:28 -0500 (EST) To: carlton@kealia.com, mec.gnu@mindspring.com Subject: Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0 Cc: eliz@gnu.org, gdb-patches@sources.redhat.com Message-ID: <20040317185528.87D7A4B104@berman.michael-chastain.com> Date: Fri, 19 Mar 2004 00:09:00 -0000 From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) X-SW-Source: 2004-03/txt/msg00394.txt.bz2 Message-ID: <20040319000900.PRCtvcmMt8B80XAG76pqvvMa0OP-_JG4hatYoZ5foE8@z> mec> gdb/826: variables in C++ namespaces have to be enclosed in quotes mec> mec> When referring to a variable in C++ code that is inside a mec> namespace, you have to put it inside single quotes. dc> This is only true in rare circumstances, and it was always true in dc> versions before 6.1! So whatever it might be, it's not a regression. dc> (Hmm: I should probably close that bug report, since it should largely dc> be fixed by now.) This test case works with gdb 6.0 and it does not work with gdb gdb-6_1-branch. # gdb 6.0, gcc 3.3.3, -gstabs+ (gdb) print (ClassWithEnum::PrivEnum) 42 $26 = yellow PASS: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 # gdb gdb-6_1-branch, gcc 3.3.3, -gstabs+ (gdb) print (ClassWithEnum::PrivEnum) 42 A syntax error in expression, near `42'. KFAIL: gdb.cp/classes.exp: print (ClassWithEnum::PrivEnum) 42 (PRMS: gdb/826) Actually, the word 'variable' is funny, because ClassWithEnum::PrivEnum is a type, not a variable. But that's what the test script calls this problem. And it's definitely a regression. mec> gdb/931: GDB could be more generous when reading types C++ mec> templates on input mec> mec> When the user types a template, GDB frequently requires the type to be mec> typed in a certain way (e.g. "const char*" as opposed to "const char *" mec> or "char const *" or "char const*"). dc> This also has always been the case. It is the case that GDB's dc> preferred form has, in some circumstances changed from 6.0 to 6.1, but dc> GDB has always had a preferred form. Yes, I know. If a user has a gdb script which pre-sets a lot of breakpoints with "break 'Foo::foo", they have to change their script with each release of gdb. That's why I consider this a regression, because it breaks user scripts. The regression in the test scripts is just an indicator that user scripts will break too. But it was worth some more text here. mec> gdb/1512: no canonical way to output names of C++ types mec> mec> We currently don't have any canonical way to output names of C++ types. mec> E.g. "const char *" versus "char const *"; more subtleties aries when mec> dealing with templates. dc> Again, this has always been the case - this isn't a regression. This is more subtle. gdb has scripted input, but how many people have scripted output for gdb? That is, when gdb changes its output from this: (gdb) ptype fvpchar type = class Foo { to this: (gdb) ptype fvpchar type = class Foo { Is that going to break a contract we have with the users? Are there any users that are going to be affected, such as front ends that are parsing or gdb's output? I'm inclined to say "yes", because we do consider the second form a KFAIL. If both output forms are okay then I think the test script should test them both. But I'm more flexible on this than I am on *input* form, where anything that used to be accepted in 6.0 and is no longer accepted in 6.1 is likely to break a user script. Michael C