From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27133 invoked by alias); 17 Mar 2004 19:03: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 27119 invoked from network); 17 Mar 2004 19:03:38 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 17 Mar 2004 19:03:38 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id B40DCC12D; Wed, 17 Mar 2004 11:03:37 -0800 (PST) To: mec.gnu@mindspring.com (Michael Elizabeth Chastain) Cc: eliz@gnu.org, gdb-patches@sources.redhat.com Subject: Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0 References: <20040317185528.87D7A4B104@berman.michael-chastain.com> From: David Carlton Date: Wed, 17 Mar 2004 19:03:00 -0000 In-Reply-To: <20040317185528.87D7A4B104@berman.michael-chastain.com> (Michael Elizabeth Chastain's message of "Wed, 17 Mar 2004 13:55:28 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-03.o/txt/msg00395.txt On Wed, 17 Mar 2004 13:55:28 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said: 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. There are some situations where the names of types that are nested within either namespaces or other types have to be enclosed within single quotes. And yes, this is a regression (though there aren't very many situations where pre-6.1 GDB's would know about the names of nested types to begin with). I should probably file a separate PR about it; it's extremely misleading to use the summary for PR gdb/826 to refer to this, because not only is this an area where GDB's behavior has significantly improved when referring to variables that aren't types, but there are situations where the user will get a better result if they don't use single quotes than when they do. 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. I don't mind mentioning this or gdb/1512, but I think the description should be clear about what has changed, and in particular that GDB has shifted from one behavior to another, neither of which is ideal. David Carlton carlton@kealia.com From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27133 invoked by alias); 17 Mar 2004 19:03: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 27119 invoked from network); 17 Mar 2004 19:03:38 -0000 Received: from unknown (HELO hawaii.kealia.com) (209.3.10.89) by sources.redhat.com with SMTP; 17 Mar 2004 19:03:38 -0000 Received: by hawaii.kealia.com (Postfix, from userid 2049) id B40DCC12D; Wed, 17 Mar 2004 11:03:37 -0800 (PST) To: mec.gnu@mindspring.com (Michael Elizabeth Chastain) Cc: eliz@gnu.org, gdb-patches@sources.redhat.com Subject: Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0 References: <20040317185528.87D7A4B104@berman.michael-chastain.com> From: David Carlton Date: Fri, 19 Mar 2004 00:09:00 -0000 In-Reply-To: <20040317185528.87D7A4B104@berman.michael-chastain.com> (Michael Elizabeth Chastain's message of "Wed, 17 Mar 2004 13:55:28 -0500 (EST)") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.4 (Reasonable Discussion, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2004-03/txt/msg00395.txt.bz2 Message-ID: <20040319000900.sEmyv5SWiAZL3K5EC4gyXhUnkE0T_zvctd7PN2NKz9A@z> On Wed, 17 Mar 2004 13:55:28 -0500 (EST), mec.gnu@mindspring.com (Michael Elizabeth Chastain) said: 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. There are some situations where the names of types that are nested within either namespaces or other types have to be enclosed within single quotes. And yes, this is a regression (though there aren't very many situations where pre-6.1 GDB's would know about the names of nested types to begin with). I should probably file a separate PR about it; it's extremely misleading to use the summary for PR gdb/826 to refer to this, because not only is this an area where GDB's behavior has significantly improved when referring to variables that aren't types, but there are situations where the user will get a better result if they don't use single quotes than when they do. 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. I don't mind mentioning this or gdb/1512, but I think the description should be clear about what has changed, and in particular that GDB has shifted from one behavior to another, neither of which is ideal. David Carlton carlton@kealia.com