[PATCH 10/12] gdb_target_is_remote -> gdb_protocol_is_remote

[Pedro Alves]

Hi!

On 2024-04-19 19:56, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:
> 
> Pedro> This is similar to the previous patch, but for gdb_protocol_is_remote.
> Pedro> gdb_is_target_remote and its MI cousin mi_is_target_remote, use "maint
> Pedro> print target-stack", which is unnecessary when checking whether
> Pedro> gdb_protocol is "remote" or "extended-remote" would do.  Checking
> Pedro> gdb_protocol is more efficient, and can be done before starting GDB
> Pedro> and running to main, unlike gdb_is_target_remote/mi_is_target_remote.
> 
> Pedro> This adds a new gdb_protocol_is_remote procedure, and uses it in place
> Pedro> of gdb_is_target_remote/mi_is_target_remote throughout.
> 
> Pedro> There are no uses of gdb_is_target_remote/mi_is_target_remote left
> Pedro> after this.  Those will be eliminated in a following patch.
> 
> Pedro> In some spots, we no longer need to defer the check until after
> Pedro> starting GDB, so the patch adjusts accordingly.
> 
> Makes sense to me, I have a question though.
> 
> Pedro> +# Check if we are talking to a remote target.  If so, bail out, as
> Pedro> +# right now remote targets can't communicate vector length (vl or svl)
> Pedro> +# changes to gdb via the RSP.  When this restriction is lifted, we can
> Pedro> +# remove this guard.
> Pedro> +if {[gdb_protocol_is_remote]} {
> Pedro> +    unsupported "aarch64 sve/sme tests not supported for remote targets"
> Pedro> +    return -1
> Pedro> +}
> 
> Seems like this spot could just use "require !gdb_protocol_is_remote" --
> any reason why you didn't do this?

Really no reason.  I've done that now locally, in the three spots I could do it.
I also simplified the comment, as most of it is obvious/redundant:

+# Remote targets can't communicate vector length (vl or svl) changes
+# to GDB via the RSP.
+require !gdb_protocol_is_remote