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

[Emi SUZUKI <emi-suzuki@tjsys.co.jp>]

Hello Jim, 

Thank you for your review and sorry for a bit later response.  

From: Jim Blandy <jimb at codesourcery.com>
Subject: Re: [RFC] checking the Z-packet support on gdbserver
Date: Tue, 18 Sep 2007 14:45:27 -0700

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

Hmmm.  But my primal worry for the current behavior is that working
with the stubs which do not support hardware watchpoints (including
the older ones) cause errors.  Although I know it would be a passive
attitude towards using hardware watchpoints, using software ones
instead of hardware ones should not cause errors.  And if the older
stubs have Z-packet supports, you can activate them by setting "set
remote Z-packet on" or something, no matter how the initial state of
Z-packets in remote_protocol_features are.  

Actually, I couldn't find any reason why the initial value of
remote_hw_watchpoint_limit defined in remote.c is -1, and it stands
for that hardware watchpoints are available...

My best regards, 
-- 
Emi SUZUKI / emi-suzuki at tjsys.co.jp