This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: RFC: Program Breakpoints
Daniel Jacobowitz wrote:
On Mon, Mar 23, 2009 at 09:50:30AM -0700, Ross Morley wrote:
It was interesting to see the matter of skipping permanent breakpoints
come up on this list. This is very similar to an issue we dealt with
a couple of years ago with Xtensa and remote targets. Our solution
has been stable for at least two years, but has not yet been prepared
for submission because I've had higher priorities (and at that time we
were way out of sync with mainline GDB). The issue is actually more
complicated than the forgoing discussion suggests.
I'd like to discuss it here and present our solution. I'll attach a
patch for our current solution relative to GDB 6.8, but I do propose
to revise it to improve some areas based on our experience (in the
next few weeks) - I'll discuss that toward the end of this post.
I read through this; overall, it looks sane. On some targets
implementing this would require the remote stub to read from pc
anyway; that's faster than GDB doing it, but not necessarily much
faster. But on some other targets the stub has to do this anyway,
or can pipeline it with other necessary operations, so it's not a big
loss.
I think you're saying it's not a big deal performance-wise to do this
without a remote protocol extension. Is that correct?
I think it's quite possible to implement the target-specific macro
STOPPED_BY_PROGRAM_BREAKPOINT(size) without any help from the remote
protocol. That is certainly an option, and might be the method of
choice for non-remote targets and some remote targets.
Having the remote stub do the break detection has other benefits.
It removes the burden of parsing the set of possible instructions
that *might* cause a stop, from GDB, and lets the stub (which has
already decided to signal a stop) simply tell GDB why it stopped.
It also handles cases where the stub decides whether to stop or not
based on factors beyond the instruction itself. Seems cleaner and
more robust. In general I think SIGTRAP is too overloaded in GDB
which has to jump through hoops to figure out why it stopped.
What I'm hoping to get from this RFC is whether the community would
accept this method, or whether it would rather take another approach
(before I put in more effort to simplify our solution and submit it).
We'd like to have a solution that we don't have to keep merging. :-)
I'll wait a few more days in case others have something to say.
Thanks,
Ross