Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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.


  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