From: Eli Zaretskii <eliz@is.elta.co.il>
To: Michael Veksler <VEKSLER@il.ibm.com>
Cc: Andrew Cagney <ac131313@cygnus.com>, "H . J . Lu" <hjl@lucon.org>,
gdb@sources.redhat.com
Subject: Re: gdb 5.2 removes the conditional breakpoints
Date: Thu, 18 Apr 2002 03:11:00 -0000 [thread overview]
Message-ID: <Pine.SUN.3.91.1020418140052.5861A-100000@is> (raw)
In-Reply-To: <OFA96DE967.33896962-ONC2256B9F.0020EB68@telaviv.ibm.com>
On Thu, 18 Apr 2002, Michael Veksler wrote:
> Your argument that "5,2 has been around for ~4
> years" does not hold water, how many people have been using 5.2 ?
You misunderstood: Andrew said that between 4.17 and 5.2, all versions of
GDB had this bug. Those versions in between are in use for 4 years, not
version 5.2 (which wasn't released yet).
> The "many
> eyeballs" effect takes place only when you "release early, release often"
> and 4 years cycle is anything but "often".
You misunderstood again: there were several versions of GDB during those
4 years, not one version.
> Now that you have a branch, people will start using it. Bugs will be
> spotted, some of them will be critical (SEGV), some will be very bad (an
> important gdb state gets reset upon restart) and others will be simply
> annoying (print syntax will not work the way it is supposed to).
Bugs which have relatively safe fixes will be fixed on the branch. Bugs
that don't have safe fixes will have to wait for the next release. New
features (as opposed to bugfixes) will have to wait, period.
Please be aware of the downside of fixing everything indiscriminately: it
means that GDB 5.2 will never be released, since ``there's always one
more bug''. So what will go into the branch and what won't is a
judgement call, not something that is self-evident.
> second bug (few hours later), was this conditional breakpoint problem. This
> problem is very annoying in C++. Every condition with virtual functions
> gets removed (at least those that I tried).
Until it gets fixed, you can work around this problem by creating a .gdbinit
file which sets all the breakpoints automatically.
next prev parent reply other threads:[~2002-04-18 10:11 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-04-17 23:40 Michael Veksler
2002-04-18 3:11 ` Eli Zaretskii [this message]
2002-04-18 9:31 ` H . J . Lu
2002-04-18 10:22 ` Daniel Jacobowitz
2002-04-18 10:34 ` H . J . Lu
2002-04-18 10:41 ` Daniel Jacobowitz
2002-04-18 9:42 ` H . J . Lu
-- strict thread matches above, loose matches on Subject: below --
2002-04-10 0:52 Michael Veksler
2002-04-17 16:57 ` H . J . Lu
2002-04-17 17:34 ` Andrew Cagney
2002-04-17 17:48 ` H . J . Lu
2002-04-17 20:20 ` Andrew Cagney
2002-03-22 9:50 H . J . Lu
2002-03-22 10:24 ` Andrew Cagney
2002-03-22 10:45 ` H . J . Lu
2002-03-22 10:27 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.SUN.3.91.1020418140052.5861A-100000@is \
--to=eliz@is.elta.co.il \
--cc=VEKSLER@il.ibm.com \
--cc=ac131313@cygnus.com \
--cc=gdb@sources.redhat.com \
--cc=hjl@lucon.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox