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

[Tom de Vries <tdevries@suse.de>]

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