On 08/05/2013 07:46 PM, Luis Machado wrote:
Risking creating more work, how does it sound to require even the
single-process (target remote) mode to use PID's for context, just like
the extended-remote mode does? I wonder how hard that is and how much
work is involved there. Implementing single-process mode on top of
multi-process... similar to all-stop on top of non-stop.
I'm confused. Is that any different from:
On 07/24/2013 12:45 PM, Pedro Alves wrote:
Originally, the multi-process extensions were always off if you connected
with "target remote"; they'd only be available to extended-remote. But
nowadays that's no longer true -- multi-process is always available even
in "target remote", if the target supports them. The push in that direction
had follow-fork in mind. So, if multi-process extensions make this easier,
we can just require them.
A big problem is backwards compatibility in this case. There are a bunch
of gdbserver/gdb versions out there that would try to speak to each
other without mentioning PID's no matter what.
Support for the multi-process extensions is broadcast in qSupported
("multiprocess+"). This works presently. Try connecting to gdbserver
with plain "target remote", and you'll see PIDs. But if the target
doesn't support the extension, then GDB will still cope. It just wont
support certain things. Fork would just be another of those things.
GDB needs to undo things from the child before detaching it
(gdb-side breakpoints, displaced stepping, etc.). Only if it's really
sure nothing will need to be removed, could pushing follow-fork-mode/detach-on-fork
to the remote side be useful. I do believe such an optimization (where
the target handles fork following) might be useful for plain "continue until
SEGV in some child" scenario, but otherwise, I believe it to be better to start
with the basics first. Make catch fork/vfork/exec work, and build up from
that. Proper vfork handling, where you have shared memory region between parent/child
until TARGET_WAITKIND_VFORK_DONE (which needs RSP modelling as well) also needs to
be factored in.
Handling these events inside gdbserver seems to be more straightforward
than doing back-and-forth to inform GDB of things that are happening.
The problem i see is the lack of displaced stepping support in
gdbserver. Everything is controlled by GDB in this case. In the future,
i imagine displaced stepping will just disappear and the debugger will
just ask for "stepi/step" and things will happen.
Sure, that's certainly possible, but I'm also certain that there'll always
be corner cases of run control where GDB will need to be informed of the fork
events, even if most handling can be done 99% of the time of the program
run in the server. "catch fork" is the most obvious example. New
fork events are a necessary condition to support these catchpoints, and
everything else can be built on top, while anything beyond the
catchpoints can be seen as optimization work, IMO. Even then, you're
_requiring_ always implementing breakpoints on the server-side that
way -- that complicates the server-side work to support forks on
software single-step targets (ARM, etc.), by a whole lot. Seems desirable
to support those too, without too many requirements.