[PATCH 10/12] gdb_target_is_remote -> gdb_protocol_is_remote

Tom Tromey tom@tromey.com
Fri Apr 19 18:56:54 GMT 2024


>>>>> "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?

Tom


More information about the Gdb-patches mailing list