This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.
> 
> Thanks,
> Pedro Alves
> 

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.

Thanks,
--Don



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]