This is the mail archive of the gdb@sourceware.org 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]
Other format: [Raw text]

Re: RFC: Program Breakpoints




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


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