[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