This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] checking the Z-packet support on gdbserver
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.