Re: [PATCH] [gdb/testsuite] Fix gdb.base/local-env.exp on remote host

Tom de Vries
2025-12-19T09:41:31Z

On 12/18/25 7:58 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>
> Tom> This doesn't work with remote host, so declare the test unsupported. Likewise
> Tom> in gdb.base/environ.exp.
>
> Tom> -gdb_assert {$saw_env == 1} "show environment displayed variable"
> Tom> +set test "show environment displayed variable"
> Tom> +if {[is_remote host]} {
> Tom> + unsupported $test
> Tom> +} else {
> Tom> + gdb_assert {$saw_env == 1} $test
>
> I've been under the impression we usually use unsupported to indicate
> that an entire .exp is being skipped,

Those uses indeed do exist.

> and for individual tests we simply
> don't invoke them.
>
> However I guess I don't really know. Do we have other cases like this?

Those uses also exist.

I grepped for unsupported in gdb.base, and the first two hits are like this.

In access-mem-running.exp, a proc test is run with non-stop and
all-stop, and this code:
...
# If debugging with target remote, check whether the all-stop
variant
# of the RSP is being used. If so, we can't run the background
tests.
if {!$non_stop
&& [target_info exists gdb_protocol]
&& ([target_info gdb_protocol] == "remote"
|| [target_info gdb_protocol] == "extended-remote")} {

if {![is_target_non_stop]} {
unsupported "can't issue commands while target is running"
return 0
}
}
...
aborts the proc in one of those cases.

Then in annota1.exp we have:
...
if {[target_info exists gdb,nosignals]} {
unsupported "send SIGUSR1"
unsupported "backtrace @ signal handler"
} else {
...

This one is from 2004.

Thanks,
- Tom