Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Jim Ingham <jingham@apple.com>
To: gdb@sources.redhat.com
Subject: 'conditions' on a breakpoint should default like 'commands'
Date: Mon, 10 Sep 2001 09:09:00 -0000	[thread overview]
Message-ID: <368274E8-A606-11D5-8DC8-000A277A8808@apple.com> (raw)
In-Reply-To: <1000126634.16985.ezmlm@sources.redhat.com>

Jason,

I don't think your suggestion will work.  The problem is that there is 
no unique way to determine whether the first word of the command after 
"condition" is a breakpoint number or a part of the condition.  For 
instance, I might write:

(gdb) cond 6 - foo == bar

This could be either

  a) the condition "-foo == bar" on the breakpoint 6, or the condition 
"6 - foo == bar" on the default breakpoint.

Jim

On Monday, September 10, 2001, at 05:57  AM, gdb-digest-
help@sources.redhat.com wrote:

> From: Jason Molenda <jason-swarelist@molenda.com>
> Date: Sun Sep 09, 2001  10:59:21  PM US/Pacific
> To: gdb@sources.redhat.com
> Subject: 'conditions' on a breakpoint should default like 'commands'
>
> 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
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham                                                           
jingham@apple.com
Developer Tools - gdb


       reply	other threads:[~2001-09-10  9:09 UTC|newest]

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

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=368274E8-A606-11D5-8DC8-000A277A8808@apple.com \
    --to=jingham@apple.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