Re: RFC: Program Breakpoints

[Ross Morley <ross@tensilica.com>]

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