'conditions' on a breakpoint should default like 'commands'

'conditions' on a breakpoint should default like 'commands'

[Jim Ingham]

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

Re: 'conditions' on a breakpoint should default like 'commands'

[Fernando Nasser]

That explains why it was not implemented.

The CLI syntax sucks.  It was intended to accommodate lazy typists.
The expression should come enclosed in "". :-(

Fernando


Jim Ingham wrote:
> 
> 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

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: 'conditions' on a breakpoint should default like 'commands'

[Andrew Cagney]

> That explains why it was not implemented.
> 
> The CLI syntax sucks.  It was intended to accommodate lazy typists.
> The expression should come enclosed in "".  [:-(] 

i'd nominate the cli parser as a better candidate for what sux. what 
syntax?  with a proper parser, parsing either:

	condition <expression> <expression>
and 
condition <expression>

might just be possible.

can jason's patch be turned into either a doco or comment addition?

andrew

'conditions' on a breakpoint should default like 'commands'

[Jason Molenda]

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

Re: 'conditions' on a breakpoint should default like 'commands'

[Fernando Nasser]

I couldn't agree more.

Fernando


Jason Molenda wrote:
> 
> 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