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

[Pedro Alves <palves at redhat dot com>]

On 11/13/2014 06:28 PM, Breazeal, Don wrote:
> On 11/13/2014 4:59 AM, Pedro Alves wrote:
>> 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.

> 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.

Yeah, but that's a problem that has to be handled
when new gdbserver is connected to old gdb anyway, even
in extended-remote mode.

> Those bad assumptions get me every time.

Sorry about that.  :-/

I'm testing a fix for the stale-threads issue, that I think
we can just go ahead and install, and I have a few other
fixes to send you.

Thanks,
Pedro Alves