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

[Pedro Alves <palves@redhat.com>]

On 01/16/2013 08:30 AM, Yao Qi wrote:
> 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 didn't say GDB, but for you/me, GDB hackers, as a debugging aid.

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

In the past when discussing some changes, and backward (in)compatibility
implications, things like "Y was never listed as qSupported
feature, but if we know GDB supports X, then we know it supports Y too,
because Y postdates it" have been put in the table.  It's a hack,
and certainly not bullet proof, and so far we managed to avoid needing
it, but it's been a last resort option (can't recall specific cases now).
That's why I said it's more _prudent_ to leave the option open.  IOW,
not paint ourselves into a corner if there's no real benefit.

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

Some features the remote target supports depend on _other_ GDB features.

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

Right, that's an example.  GDBserver's implementation of fast tracepoints
on x86/x86-64 only works if GDB can help GDBserver relocate instructions.
Note the "as possible" remark.

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

I think it'll save a few characters on the wire, when an old GDB
connects to a more recent GDBserver.  We won't get the saving
with a GDB of the same vintage as GDBserver.  So what else does
doing that gain?

Because this:

  --> qSupported:N1+,N2+,N3+; <-- XXX;N1+,N2+,N4+;

can have exactly the same result.  GDBserver knows N3 is not
supported by GDB, so doesn't send it.  Or could it have other,
possibly ambiguous semantics?

But anyway, I'll agree that my reasoning may not be seen
as a strong one.  I'm just calling for caution/prudence.

-- 
Pedro Alves