gdb/PROBLEMS ?

gdb/PROBLEMS ?

[Pedro Alves]

I looked over the described problems in gdb/PROBLEMS, and, it looks
to me that all of them fall in one of two categories: either
they've been fixed already, or aren't worth mentioning here.
Anyone wants to double check, or believes otherwise?  I'll
be happy to adjust the patch.

After the patch, all that's left is:
=======================================================================

			Known problems in GDB 7.1.50

		See also: http://www.gnu.org/software/gdb/bugs/

None worth mentioning here.
=======================================================================

While here: we haven't been maintaining gdb/PROBLEMS since 6.5,
it seems.

gdbint.texinfo has this to say:

 @section Before the Branch

 The most important objective at this stage is to find and fix simple
 changes that become a pain to track once the branch is created.  For
 instance, configuration problems that stop @value{GDBN} from even
 building.  If you can't get the problem fixed, document it in the
 @file{gdb/PROBLEMS} file.

and 

 Don't fix something on the branch unless/until it is also fixed in the
 trunk.  If this isn't possible, mentioning it in the @file{gdb/PROBLEMS}
 file is better than committing a hack.
 @item

I think that if we're not sticking with the policy
of maintaining the file anymore, we should get rid of the file
entirely.  If not, we should update the version reference in this file
as well.  But meanwhile, this is just as good (or better! GDB has
no problems!), and better than pointing at problems that are gone
already, for sure.

-- 
Pedro Alves

2010-05-02  Pedro Alves  <pedro@codesourcery.com>

	* PROBLEMS: Remove mention of all problems.

---
 gdb/PROBLEMS |  102 +----------------------------------------------------------
 1 file changed, 2 insertions(+), 100 deletions(-)

Index: src/gdb/PROBLEMS
===================================================================
--- src.orig/gdb/PROBLEMS	2010-04-19 02:05:42.000000000 +0100
+++ src/gdb/PROBLEMS	2010-05-02 17:12:46.000000000 +0100
@@ -1,104 +1,6 @@
 
-			Known problems in GDB 6.5
+			Known problems in GDB 7.1.50
 
 		See also: http://www.gnu.org/software/gdb/bugs/
 
-
-*** Build problems
-
-build/1411: build fails on hpux 10.20 and hpux 11.00 with CMA threads
-
-GDB does not build on HP/UX 10.20 or HP/UX 11.00 if the CMA
-thread package is installed.  The compile error is:
-
-  ../../gdb/hpux-thread.c:222: variable-size type declared outside of any function
-
-This happens only if the CMA thread package is installed.
-
-As a workaround, you can disable support for CMA threads
-by editing the file gdb/configure.  Find the line:
-
-  if test -f /usr/include/dce/cma_config.h ; then
-
-And replace it with:
-
-  if false ; then
-
-*** Misc
-
-gdb/1560: Control-C does not always interrupt GDB.
-
-When GDB is busy processing a command which takes a long time to
-complete, hitting Control-C does not have the expected effect.
-The command execution is not aborted, and the "QUIT" message confirming
-the abortion is displayed only after the command has been completed.
-
-*** C++ support
-
-gdb/931: GDB could be more generous when reading types C++ templates on input
-
-When the user types a template, GDB frequently requires the type to be
-typed in a certain way (e.g. "const char*" as opposed to "const char *"
-or "char const *" or "char const*").
-
-gdb/1512: no canonical way to output names of C++ types
-
-We currently don't have any canonical way to output names of C++ types.
-E.g. "const char *" versus "char const *"; more subtleties arise when
-dealing with templates.
-
-gdb/1516: [regression] local classes, gcc 2.95.3, dwarf-2
-
-With gcc 2.95.3 and the dwarf-2 debugging format, classes which are
-defined locally to a function include the demangled name of the function
-as part of their name.  For example, if a function "foobar" contains a
-local class definition "Local", gdb will say that the name of the class
-type is "foobar__Fi.0:Local".
-
-This applies only to classes where the class type is defined inside a
-function, not to variables defined with types that are defined somewhere
-outside any function (which most types are).
-
-gdb/1588: names of c++ nested types in casts must be enclosed in quotes
-
-You must type
-  (gdb) print ('Foo::Bar') x
-or
-  (gdb) print ('Foo::Bar' *) y
-instead of
-  (gdb) print (Foo::Bar) x
-or
-  (gdb) print (Foo::Bar *) y
-respectively.
-
-gdb/1091: Constructor breakpoints ignored
-gdb/1193: g++ 3.3 creates multiple constructors: gdb 5.3 can't set breakpoints
-
-When gcc 3.x compiles a C++ constructor or C++ destructor, it generates
-2 or 3 different versions of the object code.  These versions have
-unique mangled names (they have to, in order for linking to work), but
-they have identical source code names, which leads to a great deal of
-confusion.  Specifically, if you set a breakpoint in a constructor or a
-destructor, gdb will put a breakpoint in one of the versions, but your
-program may execute the other version.  This makes it impossible to set
-breakpoints reliably in constructors or destructors.
-
-gcc 3.x generates these multiple object code functions in order to
-implement virtual base classes.  gcc 2.x generated just one object code
-function with a hidden parameter, but gcc 3.x conforms to a multi-vendor
-ABI for C++ which requires multiple object code functions.
-
-*** Threads
-
-threads/1650: manythreads.exp
-
-On GNU/Linux systems that use the old LinuxThreads thread library, a
-program rapidly creating and deleting threads can confuse GDB leading
-to an internal error.
-
-This problem does not occur on newer systems that use the NPTL
-library, and did not occur with GDB 6.1.
-
-threads/2137: Native Solaris Thread Debugging broken.
-
-Use GDB 6.4 if thread debugging is needed on Solaris.
+None worth mentioning here.

Re: gdb/PROBLEMS ?

[Joel Brobecker]

> I looked over the described problems in gdb/PROBLEMS, and, it looks
> to me that all of them fall in one of two categories: either
> they've been fixed already, or aren't worth mentioning here.

I concur - with a small disclaimer on some of the entries related to
C++, where I do not follow development closely enough.

> I think that if we're not sticking with the policy
> of maintaining the file anymore, we should get rid of the file
> entirely.  If not, we should update the version reference in this file
> as well.  But meanwhile, this is just as good (or better! GDB has
> no problems!), and better than pointing at problems that are gone
> already, for sure.

Now that we have a decent bug tracking system, I think we should, at
most, direct people there. We can keep the PROBLEMS file as a redirect.
Something like this:

---------------------------------------------

                        Known problems in GDB

All known problems in GDB are now documented and tracked through
Bugzilla at: http://sourceware.org/bugzilla/.

---------------------------------------------

But we could also get rid of the file entirely; that would be fine too,
IMO.

-- 
Joel

Re: gdb/PROBLEMS ?

[Eli Zaretskii]

> From: Pedro Alves <pedro@codesourcery.com>
> Date: Sun, 2 May 2010 17:26:19 +0100
> 
> I looked over the described problems in gdb/PROBLEMS, and, it looks
> to me that all of them fall in one of two categories: either
> they've been fixed already, or aren't worth mentioning here.
> Anyone wants to double check, or believes otherwise?  I'll
> be happy to adjust the patch.
> 
> After the patch, all that's left is:
> =======================================================================
> 
> 			Known problems in GDB 7.1.50
> 
> 		See also: http://www.gnu.org/software/gdb/bugs/
> 
> None worth mentioning here.

FWIW, I'm okay with this.

Re: gdb/PROBLEMS ?

[Stan Shebs]

Pedro Alves wrote:
> I looked over the described problems in gdb/PROBLEMS, and, it looks
> to me that all of them fall in one of two categories: either
> they've been fixed already, or aren't worth mentioning here.
> Anyone wants to double check, or believes otherwise?  I'll
> be happy to adjust the patch.
>   
I'd say to just toss the file entirely, and remove mentions of it in the 
documentation.  It's really just a relic of pre-web days; I'd be 
astonished if there were any users who would think to look at it instead 
of going to our website.

Stan

Re: gdb/PROBLEMS ?

[Eli Zaretskii]

> Date: Sun, 02 May 2010 18:38:01 -0700
> From: Stan Shebs <stan@codesourcery.com>
> CC: gdb-patches@sourceware.org
> 
> Pedro Alves wrote:
> > I looked over the described problems in gdb/PROBLEMS, and, it looks
> > to me that all of them fall in one of two categories: either
> > they've been fixed already, or aren't worth mentioning here.
> > Anyone wants to double check, or believes otherwise?  I'll
> > be happy to adjust the patch.
> >   
> I'd say to just toss the file entirely, and remove mentions of it in the 
> documentation.  It's really just a relic of pre-web days; I'd be 
> astonished if there were any users who would think to look at it instead 
> of going to our website.

Are you saying that no one ever works off-line these days?

Re: gdb/PROBLEMS ?

[Stan Shebs]

Eli Zaretskii wrote:
>> Date: Sun, 02 May 2010 18:38:01 -0700
>> From: Stan Shebs <stan@codesourcery.com>
>> CC: gdb-patches@sourceware.org
>>
>> Pedro Alves wrote:
>>     
>>> I looked over the described problems in gdb/PROBLEMS, and, it looks
>>> to me that all of them fall in one of two categories: either
>>> they've been fixed already, or aren't worth mentioning here.
>>> Anyone wants to double check, or believes otherwise?  I'll
>>> be happy to adjust the patch.
>>>   
>>>       
>> I'd say to just toss the file entirely, and remove mentions of it in the 
>> documentation.  It's really just a relic of pre-web days; I'd be 
>> astonished if there were any users who would think to look at it instead 
>> of going to our website.
>>     
>
> Are you saying that no one ever works off-line these days?
>
>   

Not at all, in fact I bet I do it more than most people.  But we haven't 
been maintaining an up-to-date self-contained synopsis of open bugs, and 
as far as I know nobody is complaining that they were working offline 
the other day, and couldn't wait until getting back online to find out 
what bugs were open.

If a bug were so serious that we needed to be sure that everyone knew 
about it, even if they were using GDB while backpacking through upper 
Amazonia, then I would think we'd want it at the top of gdb/NEWS, with 
extra markup to ensure that it would be blinking red in most file 
readers. :-)

Another way to look at it is that both NEWS and PROBLEMS are chapters of 
the release note, and it's generally simpler for users if all release 
note info is in a single place.

Stan

Re: gdb/PROBLEMS ?

[Pedro Alves]

On Sunday 02 May 2010 17:26:19, Pedro Alves wrote:

> 2010-05-02  Pedro Alves  <pedro@codesourcery.com>
> 
>         * PROBLEMS: Remove mention of all problems.

Since I didn't want to spend more time on this at the moment,
and 7.2 is eminent, I applied the patch I had as is,
to the branch and mainline, without further tweaks.  GDB
has no problems left, we can all go on vacation.  :-)

-- 
Pedro Alves