Re: RFC: Program Breakpoints

[Ross Morley <ross@tensilica.com>]

Daniel Jacobowitz wrote:

>On Tue, Mar 24, 2009 at 01:32:57PM -0700, Ross Morley wrote:
>  
>
>>>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?
>>    
>>
>
>No, I was saying the opposite.  
>
Sorry for the misunderstanding.

>Sometimes it will still be expensive
>to implement the protocol extension.  
>
I would think that in most cases the stub already knows something
about what's going on, be it a single-step trap, a data watchpoint
match, or a breakpoint. It already has to distinguish some of those
cases. In many if not most cases the stub gets an exception directed
to a certain vector, an indication in a status register, or some other
clue as to the nature of the stop. It doesn't need to distinguish
types of break instruction except for size (if there's more than one).
It also needn't distinguish GDB planted breaks from program breaks.

If a target finds it's too expensive to implement the remote protocol
extension, then that target can have GDB probe the instruction.

>I'm interested in whether anyone
>sees an approach that does not require instruction scanning.
>  
>
I suspect it's going to be very target and arch specific.

>GDB has the option to cheat - it can consult the program (ELF file),
>separately from the target's view of memory.  This would not work for
>stray breakpoints inserted in the program at runtime, though.
>  
>
Not always. Program breaks are often very useful in situations where
you have code embedded in a ROM and no ELF file available. We put them
in exception handlers to allow a debugger to get control when certain
exceptions happen.

I do agree it would be good to hear if anyone has any other ideas.

Thanks,
Ross