Re: [PATCH 04/16 v3] Determine supported extended-remote features

[Pedro Alves <palves@redhat.com>]

On 11/13/2014 06:37 PM, Breazeal, Don wrote:

> Given your comment on patch 6 saying that there isn't any
> reason not to support follow fork in remote as well as
> extended-remote, the problem I was solving goes away.
> 
> The problem I thought I had was that if there was no
> agreement between GDB and gdbserver on whether the
> features were supported, then gdbserver would send
> events to GDB that it wasn't expecting in remote mode,
> and handling those looked problematic.
> 
> Those bad assumptions get me every time.  This change
> should make things simpler as long as I don't run into
> troubles with "remote".

The only thing I'm imagining at the moment, is that
in "remote" mode, gdbserver always disconnects after
a "D" / detach packet, even if there are other processes
to debug.  But that seems silly anyway and we should
probably fix it.

As I mentioned, you'll need to make old GDB against new
GDBserver work correctly, that is, make gdbserver not send these new
events if debugging with old GDB, which is not expecting them.
That can be handled by making GDB send a "fork-events+" in its
own qSupported packet, so that GDBserver knows its talking to a
new GDB.  See how the "multiprocess+" feature is handled in both
GDB and GDBserver.  For a while, GDB didn't
broadcast "multiprocess+" when connecting with "target remote".  See:

  https://sourceware.org/ml/gdb-patches/2012-01/msg00490.html

One of the reasons I wanted that on "remote" was exactly to
make it possible to have fork events without caring for
remote vs extended-remote.  :-)

If there are bigger problems, we can make GDB not broadcast
the support with plain remote for starters.  But I'd be curious
to hear what the problems are.

Thanks,
Pedro Alves