Re: [PATCH 2/3] [gdb/testsuite] Kill left-over process in gdb.base/add-symbol-file-attach.exp

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

On 2/24/25 19:05, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
> 
>>> Should this really yield unsupported, though, and not a fail?
> 
> Tom> AFAIU, the only thing that FAIL should be used for, is if gdb is
> Tom> behaving incorrectly.  In this case, gdb is not involved, this is just
> Tom> expact spawning a process for gdb to attach to.
> 
> Yeah, that makes sense.  But I think it also makes sense to
> differentiate between "cannot run because you don't have a C++ compiler"
> and "spawn failed somehow but should not have".
> 
> The former is an expected thing -- you didn't want to test C++ or Ada or
> whatever.
> 
> The latter is some kind of error.

True.

I don't think we have anything to express this currently.

One could consider ERROR, but IMO that's reserved for a problem in the 
test suite.  In this case, that may not necessarily be the case, the 
system may just have run out of enough memory to spawn a process.

I've suggested before to use UNSUPPORTED/UNTESTED for the difference 
between:
-  gdb doesn't supported it (say gdb is compiled with --disable-tui),
    and
- the environment doesn't support it,
and you could say that this is an instance of the latter.

In another case, I've suggested to use "UNSUPPORTED: <standard message>: 
$msg" for particular kinds of unsupported, like the case where a 
test-case needs specific support for an architecture, like some register 
or dwarf register number.

Thanks,
- Tom