Re: [PATCH,gdbserver] Put 'multiprocess+' in to qSupported reply if GDB supports multiprocess

[Yao Qi <yao@codesourcery.com>]

On 01/16/2013 03:55 AM, Pedro Alves wrote:
> I disagree, and it's a dangerous path to follow.   It may prove useful
> to know what exactly does a target support even if your gdb doesn't
> support it for instance, as a debugging aid.  Or GDB itself may know
> of a feature, but choose to not enable it (and therefore not broadcast
> support in its qSupported), but still infer something about the
> target from the target's reported features.  So it's more prudent to

I can't figure out why GDB wants/has to know all features that GDBserver 
supports, even some of features are not supported by GDB.  I don't find 
out a case that GDB has to lie to GDBserver, that GDB doesn't know about 
feature FOO, but is still interested in the feature FOO internally.

> make the qSupported reported features as stateless as possible.

Once we start to add features into qSupported packet (sent from GDB to 
GDBserver), the qSupoorted reply became stateful.  If the qSupported 
reply is exactly about what the remote target supports, GDB doesn't to 
tell GDBserver what features GDB supports by means of qSupported.

b.t.w, GDBserver only puts ";FastTracepoints+" into qSupported reply if 
both GDB sends "qRelocInsn+" and the target supports fast tracepoints.

This issue jumps into my eyes when I think about the query of supported 
notifications on both sides.  Both GDB and GDBserver knows different 
notifications and each of them should know what notifications supported 
in the other side.  The protocol design is as follows:

Supposing GDB knows notification N1, N2, and N3, while GDBserver knows 
notification N1, N2, and N4.

   --> qSupported:notifications=N1,N2,N3;
   <-- XXX;Notificaitons=N1,N2;

as a result, GDBserver knows N3 is not supported by GDB, so doesn't send 
it.  In the RSP interaction, I thought GDBserver doesn't have to tell 
GDB that GDBserver supports N4.  What do you think?

-- 
Yao (齐尧)