Re: gdb 5.2 removes the conditional breakpoints

Michael Veksler
2002-04-10T07:52:07Z

/References/: <20020322095020.A12445@lucon.org
<http://sources.redhat.com/ml/gdb/2002-03/msg00196.html> >
<3C9B76F5.6050809@cygnus.com
<http://sources.redhat.com/ml/gdb/2002-03/msg00198.html> >

On Fri, Mar 22, 2002 at 01:24:53PM -0500, Andrew Cagney wrote:
> > When I do
> >
> > (gdb) b 100
> > (gdb) cond 1 i == 3
> > (gdb) r
> > (gdb) r
> >
> > gdb 5.2 will remove the conditional breakpoints on Linux/x86 after I
> > restart the debug session. Am I the only one who sees it?
>
> It would be very helpful if you could illustrate this problem by
> submitting a real testcase. That way people can run it and check
> before/after effects on various platforms and GDB releases.
>

Here are the instructions for reproducing this annoying problem:

// Debugged source:
typedef int operation(int val);

int f(operation * op, int value)
{
return op(value);
}

int nop(int val)
{
return val;
}

int main()
{
return f(nop, 5);
}
// End source

Compile it on Linux using gcc 3.0.4 or redhat's 2.96 (did not test it
on other versions).
(gdb) b main
(gdb) r
Breakpoint 1, main () at t.c:15
15 return f(nop, 5);
(gdb) s
f (op=0x8048448 <nop>, value=5) at t.c:5
5 return op(value);
(gdb) b
Breakpoint 2 at 0x8048432: file t.c, line 5.
(gdb) cond 2 op(value) == value
(gdb) r
The program being debugged has been started already.
Start it from the beginning? (y or n) y

Starting program: .....
Breakpoint 1, main () at t.c:15
15 return f(nop, 5);
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x0804845a in main at t.c:15
breakpoint already hit 1 time
(gdb) q

----- Breakpoint 2 lost !!! ----

------------------------------------------------------------------------