This is the mail archive of the gdb@sourceware.cygnus.com 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]

Re: Temporary breakpoints


Seems to me that single stepping over any breakpoint should have the effect
of hitting the breakpoint, that is, counting counters, executing special
gdb commands, etc., and removing temporary breakpoints.  Single step is a
'go slow' mode, not a 'do something different' mode.

So stopping at a breakpoint should skip the normal singlestep action.  When
hitting a breakpoint which does an automatic continue, the singlestep
action should happen in place of continuing.  Same applies to watchpoints.

At 07:52 PM 8/11/99 -0700, Kevin Buettner wrote:
>Hi all,
>
>I have a question regarding temporary breakpoints...
>
>Under what circumstances should a temporary breakpoint be deleted?
>
>Sounds like a silly question, right?  Obviously, it should be deleted
>when the breakpoint is hit (provided that any conditions attached to
>the breakpoint are met).  But what constitutes hitting a breakpoint? 
>
>Clearly, running the program or continuing may cause execution to stop
>due to the breakpoint.  But what about single stepping (either step or
>next)?
>
>E.g, suppose the debugger is stopped several instructions (or
>statements) prior to the address at which you place a temporary
>breakpoint.  What should happen when you single step over the
>address/statement on which the temporary breakpoint is placed?  Should
>the breakpoint be deleted?  Or should it remain in effect until it is
>hit in some fashion that's not due to single stepping?
>
>All recent versions of gdb that I've tried on Linux/x86 will not
>remove the temporary breakpoint when you step over the temporary
>breakpoint.  OTOH, Solaris does the opposite.  On Solaris, GDB will
>remove the breakpoint when stepping over a temporary breakpoint.  I
>spoke with Stan about this briefly and we agreed that the reason for
>this difference in behavior has to do with the fact that the SPARC
>architecture doesn't have a hardware single-step, whereas the x86
>architecture does.
>
>Due to this inconsistency in behavior, I conclude that GDB will most
>likely require some fixing, but I'd like to determine what the desired
>behavior should be prior to fixing it.
>
>I have looked at the GDB manual, but, to me at least, there is some
>ambiguity about what the expected behavior should be.  In particular,
>under "Setting breakpoints", it says the following:
>
>    tbreak args 
>	Set a breakpoint enabled only for one stop.  args are the same
>	as for the break command, and the breakpoint is set in the
>	same way, but the breakpoint is automatically deleted after
>	the first time your program stops there.  See Disabling
>	breakpoints.
>
>Under "Disabling breakpoints", the GDB manual says:
>
>    A breakpoint or watchpoint can have any of four different states
>    of enablement: 
>
>	[ Descriptions of 'Enabled', 'Disabled', and 'Enabled once' elided ]
>
>	* Enabled for deletion 
>	  The breakpoint stops your program, but immediately after it
>	  does so it is deleted permanently.
>
>
>One could argue that on linux, the program is stopped due to the
>hardware single step and not the breakpoint getting hit, so it's
>behavior is correct.  But you can make a similar argument for
>Solaris which doesn't have hardware single stepping.  I think it'd
>be more useful if gdb behaved in a consistent manner regardless of
>whether the architecture supports hardware single stepping.
>
>Opinions?
>
>Kevin


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