Re: [PATCH 04/16 v2] Determine supported extended-remote features

Pedro Alves
2014-10-15T16:17:19Z

On 08/21/2014 01:29 AM, Don Breazeal wrote:
> This patch implements a mechanism for GDB to ask gdbserver what
> extended-mode features are enabled.
>
> The problems that are solved include:
>
> 1) A mechanism other than the qSupported RSP packet is needed for
> gdbserver to inform GDB about the list of extended mode features that
> are supported.

Sorry, this doesn't really make sense to me.

>
> In the existing implementation most of the information about
> supported gdbserver features is sent to GDB in response to a
> qSupported RSP message. This exchange occurs prior to GDB
> sending the "!" packet to enable extended mode. So as-is this
> message doesn't work for features that are dependent on extended-
> mode.

The differences between extended and non-extended modes are very
few, and I'd rather have fewer -- eventually merge them -- not
more.

I don't understand what motivated this. What's wrong with
just reporting the features as supported in qSupported, and
then have GDB decide whether to make use the features or not?

> Also, the qSupported exchange is intended to inform GDB about which
> packets are supported, and most of the extended mode features do not
> have associated packets. There are some features included in the
> qSupported response that do not have associated RSP messages, but the
> code comments make it clear that this practice is not acceptable for new
> packets.

Which comments?

>
> 2) A mechanism is needed to enable extended mode features when GDB
> tells gdbserver to use extended mode.
>
> The existing implementation checks for ptrace extended events
> (just PTRACE_O_TRACELONE) and enables them immediately after checking.
> This is done when the first event occurs as the program is loaded, which
> can occur before GDB has connected to gdbserver and told it whether or
> not to use extended mode.

Thanks,
Pedro Alves