This is the mail archive of the
mailing list for the GDB project.
Re: does bpstat_print stop printing prematurely?
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- To: Doug Evans <dje at transmeta dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 16 Apr 2002 09:01:39 +0300 (IDT)
- Subject: Re: does bpstat_print stop printing prematurely?
On Mon, 15 Apr 2002, Doug Evans wrote:
> What if there is 1 breakpoint that triggers and two watchpoints?
Do you actually have an example of this, or can craft one?
You see, I think it's all but impossible to have a breakpoint and a
watchpoint trigger at the same PC. That's because the CPU carefully
designs its faults and traps so that one always preceeds the other.
(For soft breakpoints, the ones implemented by inserting a breakpoint
opcode into the code, doing so overwrites the instruction that would
have caused a watchpoint to trigger, so the simultaneous triggering is
> As a user, whenever execution stops I'd kinda like to know which
> of all of my active watchpoints triggered without having to
> manually examine each one.
GDB should already cite all the watchpoints that trigger, unless there's
a bug. Again, please provide a specific example of a failure, if you can.
> Things are even more confusing if gdb prints some but not all
> of the triggering watchpoints.
Cannot reproduce this on my machine with GDB 5.1.1: if I set two
watchpoints on the same address, GDB announces both of them. Please tell
what OS did you try that on, and which version of GDB was that.
> Example: Suppose the `bs' arg to bpstat_print contains a watchpoint,
> a pc breakpoint, and another watchpoint, in that order.
> Currently bpstat_print will print the first watchpoint and the
> pc breakpoint but not the second watchpoint. Blech.
An example program that exhibits this behavior would be nice. Thanks.