This is the mail archive of the gdb-patches@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: [PATCH] Support targets that know how to step over breakpoints


On 11/27/2012 02:20 PM, Pedro Alves wrote:
On 11/27/2012 03:20 PM, Luis Machado wrote:

Meanwhile i've updated this patch for the latest cvs head.

I'm wondering if the patch is too ugly for someone to take a look at it or if it is too odd a feature to add. I suppose not.

Hopefully i can get some traction with this new refreshed and shiny version! :-)

I was hoping others could comment. :-)


Last we discussed this (probably a years ago already), I expressed my
concern with upstreaming this as is.  It's that this works by sending a regular
step command to the target, and then the target steps over any breakpoint that
may be at the current PC.  If GDB is wanting to move past a breakpoint, this still
needs to do:

  ->  vCont;s
  <- T05  (step finished)
  <- vCont;c


This seems suboptimal, though the outcome is the same.


An alternative would be to get rid of that T05, by defining new commands that
tell the target to step-over-breakpoint, or continue-over-breakpoint (and signal
variants).  E.g., sbc to mean step-break-continue:

If GDB knows the target supports stepping/continuing over breakpoints, should we bother with adding new commands at all? Or are we assuming "step over" means just single-stepping? In any case, the target can probably internally step over such a breakpoint before effectively continuing in response to a vCont;c packet. What do you think?


We would then get rid of both the vCont;s and the T05 response.


-> vCont;spc


That'd move past the breakpoint without causing a stop immediately.

Guess I need to convince myself the current design is good enough. Comments?


Though suboptimal, the design seems to do the job without being ugly. That said, the vCont;c case could be addressed for a cleaner feature.


But i think new commands are a little too much.

Testing this is also a problem i'm worried about. We can't reliably test this (and other) features that are not properly supported by gdbserver, but i suppose this is a different discussion.

Luis


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