This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [rfa/doco] PROBLEMS: add regressions since gdb 6.0


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<volatile char*>::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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]