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. > 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. Note that being globally applicable *also* applies to the GCC_EXEC_PREFIX override (at least) in certain configurations on the host - 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.) > > 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 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. > > 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). > > 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. > 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). -- Joseph S. Myers [email protected]
