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,gdbserver] Put 'multiprocess+' in to qSupported reply if GDB supports multiprocess


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 (éå)


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