On 11/29/2012 02:21 PM, Luis Machado wrote:
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 have cases where we want to vCont;c with a breakpoint at PC, and really
hit it. That's how "jump" works, but we have other cases in
handle_inferior_event that rely on that too (signal handler related things).
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.
I suppose the current proposal isn't that much of a burden to support
and I could well live with it.
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.
Actually, nowadays x86 GNU/Linux gdbserver is able to step ever
breakpoints. See linux-low.c:linux_resume. But we don't want to
use that support for regular breakpoints, because it's implemented
by the old stop everything/remove break / step/put breakpoint back / resume
dance, and displaced stepping is better. So we could hack it into
the semantics of this qSupported feature, and run the whole
testsuite with that forced enabled (e.g., with a "set remote foo" command
in a board file).