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

[Jim Blandy <jimb@codesourcery.com>]

Emi SUZUKI <emi-suzuki@tjsys.co.jp> writes:
> From: Jim Blandy <jimb at codesourcery.com>
> Subject: Re: [RFC] checking the Z-packet support on gdbserver
> Date: Thu, 13 Sep 2007 10:05:50 -0700
>
>> Emi SUZUKI <emi-suzuki@tjsys.co.jp> writes:
>> > Would anyone give me any comments how it should be treated as a whole?
>> > Defines another packet for it?  Applies as proposed and notes "it
>> > might not work with older versions of gdbserver" ?
>> 
>> I wonder, would it make sense to have GDB assume that hardware
>> watchpoints are *not* available on remote targets, and then have
>> gdbserver send a 'qSupported' packet stubfeature that tells GDB that
>> hardware watchpoints are okay?
>
> 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?

This looks good to me.  Dan should probably approve the gdbserver
side, but that looks appropriately done to me, too.

In remote.c, I noticed two things:

- You want 'resource', not 'resouce'.

- It seems to me that hardware_resource_to_Z_packet should just return
  one of the PACKET_Z[0-4], ... constants directly, instead of
  returning a Z_PACKET_* constant and letting
  remote_check_Zpacket_support convert that to a PACKET_Z? enum value.