On Wed, 14 Oct 2026, Jacob Bachmeyer wrote: > > > 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
For the build system, I assume. GCC tests generally case about how tools behave on the host (though they might care about the locale for build as well). > > 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? With testsuite save/restore logic that, as usual, only works when host = build (so this particular sub-case, of build-tree testing but where GCC_EXEC_PREFIX is needed to find some tools from the installed prefix, wouldn't work for remote hosts). > > - 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). For default_target_compile, adding a new API isn't even that complicated, given that it takes an options list including key=value entries so it would be very natural to add env=LIST as such an entry that can provide environment overrides for the host. Of course the semantics of entries in LIST (presumably the same LIST gets passed through as the extra argument to remote_exec, so all of default_target_compile, remote_load and remote_exec are defined to use the same kind of LIST for overrides) would need defining. It may make sense to define the notation used for all three cases (set an environment variable; unset an environment variable; prepend text to a PATH-like environment variable with a colon if it's already set) at the same time rather than having DejaGnu versions only supporting some kinds of overrides but not others. You previously suggested =VAR for unset alongside VAR=VALUE; maybe VAR:=VALUE or similar for "prepend with colon"? Extensions to the interface for default_target_assemble and default_link are less obvious since they don't have such an argument taking arbitrary key=value pairs at present. > 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. (GCC already uses dict in some places in its testsuites in some places, but it's certainly just an internal convenience rather than required for tracking such overrides.) > > > > 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. It looks to me like following the analysis we did previously, that the overrides correspond to roles in the testsuite rather than directly to boards. > > 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. "next test script" is liable to mean tens of thousands of tests were skipped as a result of (typically) a syntax error in a dg.exp test directive, which is functionally equivalent to the whole testsuite falling over. > > *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. The *something* would simply be the normal logging of commands run and their output; it would be natural to extend that to include environment variable settings and whether they are being ignored (of course, at present such settings in ::env don't get logged at all, so anything done to log them improves on the existing situation). If that normal logging is entirely the product of expect's spawn and log_file doing certain things by default, maybe it also requires some explicit send_log to report the information (though most such debugging information is currently reported with verbose, only at a sufficient level of verbosity, so a verbose call at level 2 would be more like existing practice). But not noisy WARNINGs or ERRORs. > > > 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. It implies a shell that can run the kinds of commands generated in ssh_exec. -- Joseph S. Myers [email protected]
