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


On Fri, Feb 17, 2006 at 09:38:49PM +0200, Eli Zaretskii wrote:
> > 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?

That's how we get the source line printed when we stop, isn't it? 
I'd ask the opposite question, but I suspect the use of PRINT_UNKNOWN
has something to do with how the old/new values get printed out.

> > 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.

There are two events in hardware, yes - but "GDB will always see these
two as separate events" is not accurate.  Suppose we've got an
instruction at foo+0x10 that stores to a watched address and at
foo+0x16 that has a breakpoint set on it.  The watchpoint will trigger,
stopping GDB at foo+0x16.  At this point, we were stopped by the
watchpoint, but we'll never hit the breakpoint - if the user "continue"s,
GDB will politely step around the breakpoint.  In effect, we've
hit the watchpoint and breakpoint simultaneously, and IMO it would
be appropriate to let the user know about both of them.

What do you think?

-- 
Daniel Jacobowitz
CodeSourcery


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