On Friday 15 January 2010, Igor Skochinsky wrote:
This is pretty standard. Most targets cannot continue from a
breakpoint (i.e. they just stop at the same position), so GDB removes
breakpoint, steps, puts it back and then continues.
On the other hand, if there's no breakpoint at the current
On Friday 15 January 2010, David Brownell wrote:
On Friday 15 January 2010, Igor Skochinsky wrote:
This is pretty standard. Most targets cannot continue from a
breakpoint (i.e. they just stop at the same position), so GDB removes
breakpoint, steps, puts it back and then continues.
On the
Hmm ... is this a bug you've observed, or is this something
you've wondered after poking through the code?
I recall setting breakpoints through the Tcl interface and
having them behave correctly. Haven't tried to do that any
time recently, though. And I could believe there's a bit
of a semantic
On Thursday 14 January 2010, yintang gu wrote:
Hmm ... is this a bug you've observed, or is this something
you've wondered after poking through the code?
I recall setting breakpoints through the Tcl interface and
having them behave correctly. Haven't tried to do that any
time recently,
I'll hope someone else chimes in with some insights here. This
kind of needs to get sorted before 0.4 freezes.
Here is another tidbit:
If you execute c, then first a step packet is sent, then a continue
packet. Weird, uh?
--
Øyvind Harboe
US toll free 1-866-980-3434 / International +47 51
In function arm7_9_resume(struct target *target, int current, uint32_t address,
int handle_breakpoints, int debug_execution) (arm7_9_common.c), the argument
handle_breakpoints is only used to deal with the condition in which a
breakpoint is set at current PC.
But in function arm11_resume()
