Re: [patch/ob] not_a_breakpoint -> not_a_sw_breakpoint

[Daniel Jacobowitz <drow@mvista.com>]

On Fri, Aug 16, 2002 at 01:33:59PM -0400, Andrew Cagney wrote:
> > Great.  I'm going to have to think about this a little more though; if
> > you look in infrun.c you'll see that this parameter sometimes comes
> > from catchpoints, which is unfortunate since we have nowhere that
> > indicates whether a catchpoint is affected by DECR_PC_AFTER_BREAK or
> > not.
> 
> See my e-mail to Kevin.  it decides if 
> DECR_PC_AFTER_[SOFTWARE_]BREAK[POINT_TRAP] should be applied.
> 
> > (For i386/Linux, when I'm done with it, I believe that throw and catch
> > catchpoints WILL be affected by decr_pc_after_break.... and that
> > fork/exec/vfork catchpoints WON'T be.  I had to hack around this in my
> > work tree.)
> 
> Are throw/catch events implemented using software breakpoints that are 
> entered into the breakpoint table?
> 
> One of the characteristics of the software single step breakpoints is 
> that they are not entered into the breakpoint table.  This is why Joel 
> needs to hide them from core GDB :-)
> 
> I think fork/exec events can be treated separatly.

Well, throw/catch events will be (haven't done it yet) implemented
using (some kind of) breakpoints.  Whether they will be in the table or
not is a different question.  I personally think that the way
catchpoints are handled at the moment is all wrong, since it relies on
the to_wait method to determine what event occured; which is perfect
for event reporting mechanisms and awful for events synthesized by
breakpoints.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer