This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MI: reporting of multiple breakpoints


> From:  Vladimir Prus <ghost@cs.msu.su>
> Date:  Fri, 17 Feb 2006 18:47:59 +0300
> 
> > The CLI does the same thing; so does the core of GDB, unsurprisingly.
> 
> For ordinary breakpoints, yes. For watchpoints, not quite:

That's because breakpoint.c treats breakpoints and watchpoints
differently in this regard, I don't know why.  You will see that
print_it_typical returns PRINT_SRC_AND_LOC for breakpoints, but
PRINT_UNKNOWN for watchpoints.

Does anyone know why we return PRINT_SRC_AND_LOC for breakpoints?

> CLI reports two watchpoints, and MI reports just one.

Both should report all of them, IMHO.

> I did not test more complex combinations, like mix of watchpoints
> and breakpoints that trigger on the same line.

I don't think you will find anything interesting by mixing those, at
least not on x86.  Setting a breakpoint replaces the original
instruction by a special opcode, so the original instruction cannot
run and trigger the watchpoint.  After the breakpoint is hit, GDB
restores the original instruction, and then the watchpoint triggers.
So GDB will always see these two as separate events, each one stopping
the inferior in its own due time.

Similar things happen if you use hbreak: the x86 architecture causes
the hardware breakpoint to break _before_ the instruction runs, but  a
watchpoint breaks _after_ the instruction runs.  So again there are
two separate events.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]