Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jason Molenda <jason-swarelist@molenda.com>
To: gdb@sources.redhat.com
Subject: 'conditions' on a breakpoint should default like 'commands'
Date: Sun, 09 Sep 2001 22:59:00 -0000	[thread overview]
Message-ID: <20010909225921.A16335@shell17.ba.best.com> (raw)

The "commands" command in gdb will assume the most recently set
breakpoint if no breakpoint number is provided.  The "condition"
command in gdb requires a breakpoint number.  This seems unnecessarily
inconsistent.  My best guess as to the thinking of the original
implementer was that users could set the condition on the breakpoint
line directly, so they wouldn't often be putting a condition on
the bp right after setting it.

The difference in breakpoints.c is minor; commands_command reads

  p = arg;
  bnum = get_number (&p);

Whereas condition_command reads

  if (arg == 0)
    error_no_arg ("breakpoint number");

  p = arg;
  bnum = get_number (&p);

I checked back through the gdb v3.0 era releases, and these commands
have always behaved this way--I can't find any historial reason
for them to act differently.  It was the case that get_number () didn't
exist back then, so maybe that helped to shroud the similarity of the
two commands.


I'd like to make condition default to the most recent breakpoint
if no argument is provided.  If anyone agrees with this, I'll supply
a patch to the code, the documentation, and a test case.  I don't
see this as causing problems for existing users -- typing "cond 5"
will still set a breakpoint on bp #5; the only difference is that
if you type "cond", gdb will do something whereas it used to return
an error message.

Thanks,

Jason


             reply	other threads:[~2001-09-09 22:59 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-09-09 22:59 Jason Molenda [this message]
2001-09-10  5:57 ` Fernando Nasser
     [not found] <1000126634.16985.ezmlm@sources.redhat.com>
2001-09-10  9:09 ` Jim Ingham
2001-09-10  9:54   ` Fernando Nasser
2001-09-11  8:00     ` Andrew Cagney

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=20010909225921.A16335@shell17.ba.best.com \
    --to=jason-swarelist@molenda.com \
    --cc=gdb@sources.redhat.com \
    /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