On 10/14/26 11:28, Joseph Myers wrote:
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).
All non-remote boards implicitly inherit DejaGnu's environment,
including pseudo-remote targets like QEMU.
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).
So these are situations in which GCC's testsuite currently fails to run,
and we want to extend the framework to enable testing in these situations?
- 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"?
VAR:=VALUE looks to much like make's static assignment. VAR+=VALUE is
generally used for /append/. Maybe the better option would be to allow
"${VAR}" to appear in VALUE? Then prepending to PATH would simply be
"PATH=/where/ever:${PATH}".
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 interfaces are actually target_compile, target_assemble, etc.
because default_target_compile, default_target_assemble, etc. are
internal procedures that are documented as internal. Do not expect
overriding them to reliably work and you should not call them directly
from testsuite code. They will eventually disappear from the global
namespace.
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.)
Exactly, with GDB also relying on Tcl 8.5 features, maintaining
framework compatibility with Tcl 8.4 is starting to become moot.
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.
The problem is that you could have overrides for this-role, overrides
for this-board, and overrides for this-board-in-this-role.
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.
Should dg.exp also catch errors and attempt to resume, then?
I will have to think about how to expose the internal support DejaGnu
uses for that. While catch(n) is a Tcl builtin, the error list that is
repeated at the end of the test run is a DejaGnu feature. Then again,
lib/dg.exp *is* part of the framework, so it could just use the internal
interface.
*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.
At minimum, something like {verbose -log "environment overrides
dropped"} will be included.
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.
...but not necessarily a usable environment. (I have seen weird
embedded systems. Someone developed those things.)
-- Jacob
