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

[Mark Kettenis <kettenis at wins dot uva dot nl>]

   From: patl@cag.lcs.mit.edu (Patrick J. LoPresti)
   Date: 08 Feb 2000 09:55:28 -0500

   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*.

Depends on what you call broken I guess.  Stock GDB 4.17 was pretty usable.

   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 just noticed that the FreeBSD folks seem to have a solution for the
dlopen()/dlclose()/dlopen().  It isn't that obscure.  It simply isn't
implemented.  That might take a few hours for a competent GDB hacker, and
a few more for somebody who doesn't know GDB too well.  But the
FreeBSD code looks reasonable at first sight, so I think I can fix
things eventually.  Just not overnight.

Why do people think that breakpoints in shared libraries don't work at
all?  They didn't work in GDB 4.18, because of a bug-fix for SunOS 4
that broke most of the other systems.  That was corrected shortly
after the release, and if you use a recent GDB snapshot everything
seems to work fine.

If you can privide a test-case where setting breakpoints in a shared
library breaks things in a recent GDB snapshot, please do so.  AFAIK
none of the people who're actively hacking on the GDB code is aware of
such a problem.

   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.

Well, the hack is pretty gross, AFAICT only relevant for the multiple
dlopen()/dlclose() scenario, and needs some work anyway.  Sam provided
HJ with two patches that seem to address the same problem, and the
code that HJ sent yesterday looks completely bogus to me!  The patch
affects all platforms using SunOS-style shared libraries or ELF shared
libraries.  And, can we please first establish what the exact bug is before
we start trying to hack around it!

Mark