Re: Preparing for the GDB 5.0 / GDB 2000 / GDB2k release

[Stan Shebs <shebs at shebs dot cnchost dot com>]

"Patrick J. LoPresti" wrote:
> 
> Andrew Cagney <ac131313@cygnus.com> writes:
> 
> > With that said, I would consider a one month gap between 5.0 and 5.1 to
> > be unrealistic. I'd also consider it un-reasonable to mandate the
> > acceptance of patches just because a reasonable solution isn't
> > available.
> 
> I think it depends on the situation.  At this point, stock GDB has
> been broken on Linux/x86 for several *years*.
> 
> The problem with debugging across dlopen()/dlclose()/dlopen() sounds
> complicated.  It is also fairly obscure.  However, being unable to use
> breakpoints in *any shared library at all* is not obscure.  It makes
> stock GDB extremely painful for a lot of uses.  If GDB 5.0 is released
> with the same problem, I suspect the word among Linux developers will
> be the same as it has been for the last few years: "Stock GDB is
> broken; don't use it."

I'll second this sentiment here.  GDB is supposed to be the standard
debugger for the GNU project, and GNU/Linux is one of the GNU OSes.
The users should be able to expect that a major release of a standard
GNU tool will be fully functional on all GNU OSes.

> The SamL/H.J. patches fix the problem, as far as we can tell here.
> And those patches are not very large.  Is it really so hard to put
> them in and fix the problem the Right Way later?  The argument "we
> can't accept every hack" is pretty weak.  You are not being asked to
> accept every hack, you are being asked to accept a single hack which
> addresses a very serious problem on a major platform.

Having paid the price many times for accepting "temporary patches" :-(,
I would only support that if we were really desperate - for instance, if a
bad bug showed up on the release branch mid-process.  In this case though,
we're talking about release schedule, and it seems perfectly reasonable
to me to push back the schedule by a couple weeks if that will yield
better shlib debugging, and avoid a need to fork versions.

Stan