rules for conditional breakpoints

rules for conditional breakpoints

[Peter Jay Salzman]

hi all,

what exactly are the rules for conditional breakpoints?  clearly the
condition can use the standard boolean operators, along with the logical
qualifiers:

   break main if i > 3
   break test.c:3 if i !=0 && j <=0

but libc functions linked to the code also seem to work:

   break 40 if *(string + strlen(string)) != '\0'

from a previous email i sent to this list, i gather that strlen() works
"by accident", and only functions that return an int work.  so this
won't work, even with typecasting:

   break 1 if (double)cos(0) == 1.0L

so, this seems to be the rule for conditional breakpoints:

1. equality/inequality operators. ie:
       <, >, <=, >=

2. logic operators.  ie:
      &&, ||

3. libc functions linked to code but ONLY if they return an int.  ie:
      strlen(), abs()

is this correct?

thanks!
pete

-- 
Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D

Re: rules for conditional breakpoints

[Eli Zaretskii]

On Wed, 25 Sep 2002, Peter Jay Salzman wrote:

> what exactly are the rules for conditional breakpoints?

If that's not clear from reading the manual, I think we should fix the 
manual.

Re: rules for conditional breakpoints

[Peter Jay Salzman]

hi eli,

unfortunately, the user manual doesn't really say much about this.  the
relevent section is 5.1.6 (break conditions) which references section
8.1 (expressions).

in the first paragraph os 5.1.6:

   A condition is just a Boolean expression in your programming language
   (see section 8.1 Expressions).

but this is where my confusion is coming from.  here is a boolean
expression:

   break main if cos(0.0) == 1.0

the condition "cos(0.0) == 1.0" is a boolean expression.  it's either
true or false.  yet it's not valid in a conditional breakpoint.

looking further down the section 5.1.6, it mentions that user defined
functions are allowed in conditions.



looking at section 8.1, it has something relevent:

   Any kind of constant, variable or operator defined by the programming
   language you are using is valid in an expression in GDB.  This
   includes conditional expressions, function calls, casts and string
   constants.  It unfortunately does no include symbols defined by
   preprocessor #define commands.

this is kind of ambiguous whether "the programming language" includes
glibc or not.  if it doesn't, then i'm unsure what "functions" this
paragraph is talking about.  if it does, then it directly conflicts with
my "cos(0.0) == 1.0" as an example of something that should work but
doesn't.

either way, i can appreciate the fact that the user's manual doesn't
have examples.  that's what books are for.  but it seems to me that it
leaves some details in an ambiguous state.


this email was longer than i intended.  thanks for reading down to here.
:)

  peter



begin Eli Zaretskii <eliz@is.elta.co.il> 
> 
> On Wed, 25 Sep 2002, Peter Jay Salzman wrote:
> 
> > what exactly are the rules for conditional breakpoints?
> 
> If that's not clear from reading the manual, I think we should fix the 
> manual.

-- 
Fingerprint: B9F1 6CF3 47C4 7CD8 D33E 70A9 A3B9 1945 67EA 951D

Re: rules for conditional breakpoints

[Daniel Jacobowitz]

On Wed, Sep 25, 2002 at 11:40:06PM -0700, Peter Jay Salzman wrote:
> hi eli,
> 
> unfortunately, the user manual doesn't really say much about this.  the
> relevent section is 5.1.6 (break conditions) which references section
> 8.1 (expressions).
> 
> in the first paragraph os 5.1.6:
> 
>    A condition is just a Boolean expression in your programming language
>    (see section 8.1 Expressions).
> 
> but this is where my confusion is coming from.  here is a boolean
> expression:
> 
>    break main if cos(0.0) == 1.0
> 
> the condition "cos(0.0) == 1.0" is a boolean expression.  it's either
> true or false.  yet it's not valid in a conditional breakpoint.

If you had debugging information in your library, it would work, as I
tried to explain last time.  Or you can do this:

(gdb) set $p = (double (*) (double)) cos
(gdb) ptype $p
type = double (*)()
(gdb) p cos(2.)
$2 = 14880
(gdb) p $p(2.)
$4 = -0.41614683654714241

> looking further down the section 5.1.6, it mentions that user defined
> functions are allowed in conditions.
> 
> 
> 
> looking at section 8.1, it has something relevent:
> 
>    Any kind of constant, variable or operator defined by the programming
>    language you are using is valid in an expression in GDB.  This
>    includes conditional expressions, function calls, casts and string
>    constants.  It unfortunately does no include symbols defined by
>    preprocessor #define commands.

That's out of date.  Macros work now if you have the right debug info.

> this is kind of ambiguous whether "the programming language" includes
> glibc or not.  if it doesn't, then i'm unsure what "functions" this
> paragraph is talking about.  if it does, then it directly conflicts with
> my "cos(0.0) == 1.0" as an example of something that should work but
> doesn't.

Perhaps it could be clearer.  What it means is, the _concept_ of a
function call, as an operation, is valid.  The function you call has to
be defined with debug info.  This is actually misleading since a lot of
what is in glibc is specified by the language standard...


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: rules for conditional breakpoints

[Jim Blandy]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> On Wed, 25 Sep 2002, Peter Jay Salzman wrote:
> 
> > what exactly are the rules for conditional breakpoints?
> 
> If that's not clear from reading the manual, I think we should fix the 
> manual.

The expressions allowed in conditional breakpoints are exactly those
allowed in "print".  Peter assumed that the restriction had something
to do with conditional breakpoints, but that's not so.  The manual's
description of conditional breakpoints is perfectly clear.

What should be clarified, I think, is the description of expressions.
I seem to remember issues like this having come up before.  I'd
suggest putting a clarification in ``Expressions'', pointing out that,
while GDB *can* reference variables and call functions for which it
has no debug info, it assumes they're `int' and `int () (int)'.  When
that's wrong, one should expect the ensuing problems.

I'm too drowsy to suggest any decent wording at the moment.  Sorry.