On 10/13/26 12:02, Joseph Myers wrote:
On Mon, 12 Oct 2026, Jacob Bachmeyer wrote:
A design requiring most of 70 remote_exec calls to be adjusted to use an
extra argument, and additional calls made sure to use that argument
whenever they are added (alternatively: all replaced by calls to a local
wrapper, and then making sure no more direct remote_exec calls for host or
target are added in future) doesn't seem that robust compared to having a
standard system for accumulating environment overrides (where the extra
argument to remote_exec takes first precedence, then the accumulated
overrides).
I dispute your premise---this is the kind of adjustment that a moderate amount
of Emacs Lisp code can do quite easily. There is a sample in DejaGnu's
ChangeLog from the last time I had to update GPL notices.
It's not just the one-off change, people could easily be contributing
patches for the next decade that they developed a long time ago and that
have new remote_exec calls that would need fixing, and where subtle
breakage occurs only in certain configurations when such new calls get
into the testsuites.
Sometime in the next decade, the framework is expected to gain the
ability to properly set environment overrides with dynamic extent. :-)
Also, vigilance for such changes is simply part of software maintenance.
Also, not all of the remote_exec calls may even need to pass environment
overrides. You previously said that only some tests rely on them.
Some settings such as LC_ALL and LANG are more or less globally applicable
on the host (but absence may only result in breakage depending on the
user's environment). Likewise for paths to find target libraries on the
target.
DejaGnu now already sets LANG, LC_ALL, and a long list of LC_* variables
to "C" during early initialization. Anything that inherits DejaGnu's
environment will run in the POSIX locale. (We actually set LC_ALL=C in
the runtest shell script because Tcl 9 needs it set when the interpreter
is initialized.)
In fact, I would be willing to hardwire LANG=C as a default environment
override unless further overridden by the testsuite. Test cases should
never inherit the user's locale.
Note that being globally applicable *also* applies to the GCC_EXEC_PREFIX
override (at least) in certain configurations on the host
This looks like something that has a current solution. How is
GCC_EXEC_PREFIX currently handled?
- and that's
probably also relevant for calls through target_compile (where GCC has its
own wrappers gcc_target_compile etc.). So you also need a way to ensure
the desired host overrides make their way through to remote_exec calls
from default_target_compile via target_compile. (target_assemble and
target_link don't seem to be used in the GCC testsuite, but it would be
odd for an override mechanism to allow environment variables to get
through to remote_exec called from target_compile but not the other two.)
Of course it does... default_target_compile is slated for a rewrite in
1.6.5 (it was slated for a rewrite in 1.6.4 but enough bug fixes have
accumulated to push major refactoring---like adding a new API for remote
environment overrides--to another release).
The 1.6.4 release will also be the last release with full support for
Tcl 8.4. Among other things, that means using Tcl dict(n) to handle
variable lists will be available in 1.6.5.
My GCC patches don't replace all environment manipulation, just many of
the places including all those that are most important for remote target
testing, but they certainly make an incremental improvement over direct
::env use and facilitate further such improvements. That's the expected
use of such a feature - replacing ::env, not introducing global state to
testsuites that lack it.
If you are using ::env to manipulate the environment of remote processes, you
already have a problem. Further, as you have said before, using ::env to
manage "target" (or even "host") variables is wrong because those environments
are distinct from "build" and should not be conflated.
The point is to fix both problems at once by having a suitable interface
for environment manipulation that's easier to use correctly while also
working with host and target. And considering the amount of local code in
the GCC testsuites, the more that can be a generic facility for all
testsuites with similar uses for environment manipulation rather than just
GCC's, the better.
The point is that there is another interface already in development in
DejaGnu that will address a key part of this problem (save/restore
managed by the framework) and having two interfaces for equivalent
functionality is a recipe for trouble.
The suggestion of associating just with the aliases "build", "host",
"target" (and thus checking in remote_load and remote_exec before the
translation from alias to board name takes place) was to support the case
where host and target use the same board but need different overrides.
Suppose some overrides are registered under the build/host/target alias and
some are registered under the actual board name. How should those interact
and is there a single answer to that question that is appropriate for all
testsuites?
The override system here would only support the aliases, not registering
overrides under board names at all. That's what makes sense for testing
GCC at least.
This looks to me like the type of arbitrary limit that GNU software is
not supposed to have.
No, I'm suggesting that remote_exec host should not fail just because
there's a request to pass through LC_ALL=C that it can't handle. The
testsuite should decide if certain environment variable settings are ones
that should result in skipping a test (ideally a result of UNRESOLVED)
versus "best efforts" ones that may not be relevant because the particular
test setup has another way of handling those (many path-related variables
are irrelevant for installed testing, for example; LC_ALL=C is irrelevant
on a host where that's the default).
No, remote_exec will not fail if the target does not support environment
overrides. Instead, a WARNING (or perhaps ERROR?) will be reported when the
environment override list is discarded. Remember that older versions of the
framework will silently discard the extra argument, so passing environment
overrides to remote_exec or remote_load is always "best effort" anyway.
An ERROR is effectively "whole testsuite run falls over" (it has to be
treated as such when looking at test results).
No, that is a Tcl error (which is an "abort"), and DejaGnu now attempts
to recover from *those* by simply running the next test script in the
list, after inserting an UNRESOLVED result as a proxy for an unknown
number of tests that were never attempted. Stopping immediately upon a
Tcl error was something the GDB developers *really* did not want.
An ERROR (1 by default, but the threshold *is* configurable) only
converts the next test result to UNRESOLVED. Similarly, by default, 3
WARNINGs convert the next test result to UNRESOLVED, but execution
continues in both cases.
That would be incredibly noisy and undesirable (even if it could be
overridden by making the board file take "args" to ignore the request). A
single GCC testsuite run produces over 700000 PASSes; adding a similar
number of WARNING or ERROR is hardly a good idea (even a single ERROR is
something to avoid, given that they normally mean "a typo in a test
stopped a large part of the testsuite from being run at all", so adding
"expected" ERRORs would drown out the serious ones).
How is "the testsuite attempted to do something that the target is *known* to
not support" not worthy of at least a WARNING to the user? Think about the
developer who is trying to figure out why a test FAILed---and the cause is
that an environment setting needed for that test to pass did not propagate to
the target.
There needs to be *something* in the log to point at the cause of such a
failure.
*One* WARNING might make sense for the first time environment variables
are not propagated. Hundreds of thousands of warnings is just noise.
There still needs to be *something* in the log for each time. Proximity
is important here---a developer investigating a failure should *never*
have to examine *other* tests to find a known probable cause for the
failure.
If you are talking about a board description file, then we can add a key to
board_info that declares support for environment overrides on a specific
board. However, your initial patch appears to put this on the *protocol*
rather than the board, which I anticipate will have obnoxious edge cases,
especially with near-bare-metal targets: Murphy's Law says that there is a
board out there with an SSH-capable debug monitor that has no environment at
all.
ssh.exp isn't suitable for such a debug monitor anyway; it assumes
availability of a shell, it's for use of ssh to connect to a Unix-like
system to run commands in place of the older rsh.exp, not completely
arbitrary use of ssh to connect to some other kind of system entirely.
It would be ssh_exec that determines the availability of environment
variable support. So naturally it should also be something in ssh.exp
that declares availability of environment variable support (and something
in the core remote.exp framework that declares the support in the case of
local execution, I suppose).
"SSH-capable" implies a quasi-shell, but there is a wide variety of
weird hardware out there.
-- Jacob
