This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [patch/ob] not_a_breakpoint -> not_a_sw_breakpoint
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