This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
A couple more `cond' oddities
- From: Tom Tromey <tromey at redhat dot com>
- To: Gdb List <gdb at sources dot redhat dot com>
- Date: 04 Dec 2001 21:15:19 -0700
- Subject: A couple more `cond' oddities
- Reply-to: tromey at redhat dot com
I'm using yesterday's cvs trunk gdb.
My platform is x86 Red Hat Linux 6.2.
I've observed a couple oddities in the `cond' command.
Here's some text from my debug session:
(gdb) cond 2 start_PC == 135
No symbol "start_PC" in current context.
(gdb) c
Continuing.
Error in re-setting breakpoint 2:
No symbol "start_PC" in current context.
[ ... ]
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x08048ae5 in main
at ../../../gcc/libjava/gij.cc:59
breakpoint already hit 1 time
2 breakpoint keep n 0x4032f051 in _Jv_BytecodeVerifier::verify_instructions_0() at ../../../gcc/libjava/verify.cc:1836
[ ... ]
(gdb) c
Continuing.
[New Thread 2049 (runnable)]
[New Thread 1026 (runnable)]
Breakpoint 2, _Jv_BytecodeVerifier::verify_instructions_0() (this=0xbffff1e0)
at ../../../gcc/libjava/verify.cc:1836
(gdb) cond 2 start_PC == 135
(gdb) info b
Num Type Disp Enb Address What
1 breakpoint keep y 0x08048ae5 in main
at ../../../gcc/libjava/gij.cc:59
breakpoint already hit 1 time
2 breakpoint keep y 0x4032f051 in _Jv_BytecodeVerifier::verify_instructions_0() at ../../../gcc/libjava/verify.cc:1836
stop only if this->start_PC == 135
breakpoint already hit 1 time
What you see here is that I've tried to set a condition on a
breakpoint.
First, gdb claims that it fails. gdb seems to be evaluating my
expression in my current context and not the context in which the
breakpoint occurs, I don't know. `start_PC' is definitely a valid
variable at the breakpoint location, and if I get to the breakpoint I
can print it, etc.
Next, gdb seems to try to use my breakpoint condition even though it
supposedly failed. `info b' tells me that there is no condition! But
I if type `cond 2' gdb tells me that the breakpoint is "now
unconditional", and things start working again. Later on I can set
the condition and `info b' tells me it is there.
I find much of this behavior confusing, and I think it is a regression
from earlier versions of gdb.
Tom