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

[Pedro Alves <palves at redhat dot com>]

On 10/31/2014 11:28 PM, Don Breazeal wrote:
> This patch implements a mechanism for GDB to determine what
> extended-mode features are enabled in gdbserver.  This is
> a preparatory patch for extended-remote fork and exec event
> support.
> 
> Several new features are included in the potential response to
> the qSupported packet, denoting fork, vfork, and exec events.
> and exec events.  Note that vfork_done events are not represented
> here, because if vfork events are supported, gdbserver will fake
> up a vfork_done event for GDB even if the target doesn't provide
> direct support for vfork_done.
> 
> A number of changes were required to make this work:
> 
> 1) Sending the "!" (use extended protocol) packet before sending the
>    qSupported packet so that gdbserver knows it is in extended mode
>    when responding to qSupported.  Previously qSupported was the
>    first packet sent.

I don't think we should do this.  What's wrong with always
reporting support for the feature ?

If GDB doesn't want them with "target remote", then it won't use
them.

If the server needs to know whether GDB supports or wants
the feature before activating it, then GDB's qSupported query
should indicate it.   See the "multiprocess+" feature.

As I mentioned before, I'd rather have fewer differences between
"remote" and "extended-remote", not more.

Thanks,
Pedro Alves