Re: [RFC] checking the Z-packet support on gdbserver

[Jim Blandy <jimb at codesourcery dot com>]

Emi SUZUKI <emi-suzuki@tjsys.co.jp> writes:
> Well, I understood casually that the answer of 'qSupported' packet
> would tell the support for the other 'q' packets from the current
> implementaion...  According to the description in the info, definitely
> it would make sense.  How about the attached?

Actually, thinking more carefully: what effect will this change have
on existing stubs that do support hardware watchpoints, but don't
include 'Z0+', etc. in their qSupported responses?  Won't it mean that
new GDBs will decline to use hardware watchpoints with them?

It seems to me that, when GDB has no information about 'Zx'
availability, it should continue to assume that they are available and
then get errors if not, as it does now, but it should also work with
smarter stubs, like your patched GDB server, to provide a better user
experience.

So, would it make more sense for the initial state of the Z packets in
remote_protocol_features to be PACKET_SUPPORT_UNKNOWN, and for
gdbserver to transmit either Zx- or Zx+ as appropriate?  Thus, in your
case, as soon as GDB connected to the target it would know that
hardware watchpoints weren't available, but on connection to some
older stub which said nothing about the Z packets in its qSupported
response (if it gave such a response at all), GDB would continue to
try hardware watchpoints.