On Thu, 8 Oct 2026, Jacob Bachmeyer wrote:
> Testsuites are free to define their own Tcl variables and to use namespaces
> outside of ::dejagnu:: and ::DejaGnu:: (which are reserved for the
> framework). What prevents the GCC testsuite from tracking its own environment
> overrides and building the final list at each remote_exec call?
There are about 70 remote_exec calls in the GCC testsuites (mostly for
host, some for build or target), and one remote_load, and about 20
${tool}_load. And the main way tests are run is via dg-test which is
provided by DejaGnu (and which uses ${tool}_load, which uses remote_load,
which uses call_remote, which uses standard_load if the board doesn't
provide its own *_load, which uses remote_exec).
Reliably handling some environment settings for all host code or all
target code means that requiring things to be passed explicitly on every
call to those functions does not seem a very robust design; enough of the
uses are effectively global state that it makes sense to treat them as
such, and then possibly allow a further level of overrides on the
remote_exec (or remote_load, or ${tool}_load) calls only for those call
sites where a very local override is the natural model. While GCC does
rename some of those functions and replace them by wrappers for various
purposes, that also seems to be something that you're discouraging.
> (The global namespace has a lot of stuff in it. New features like this should
> use namespaces to reduce future maintenance burdens around avoiding name
> collisions; I suggest ::gcc_test::env:: to start the proverbial wheels turning
> if needed.)
Obviously code directly in DejaGnu such as dg.exp can't use GCC-specific
names like that. And I don't think the use for environment overrides at
various levels, as opposed to just where it's convenient to name the
overrides at a particular call site, is something specific to GCC.
> Putting the interface boundary at remote_exec would preserve a proper
> mechanism-vs-policy split: DejaGnu would immediately provide only the
> mechanism to apply environment overrides, leaving managing what overrides are
> needed to testsuites.
>
> Since that mechanism is needed regardless of higher-level features built
> around it, exposing it is a trivial burden on future maintenance.
I think the interface needs to include "globally set / push / pop
overrides", not just "execute a program with these overrides".
> > Mixing them up into a single environment is not a good idea, especially
> > when PATH-like settings are involved (PATH or LD_LIBRARY_PATH on the build
> > system or host should not be set to point to libraries or executables for
> > the target, which may have a different architecture as well as a different
> > root filesystem with different paths). The environment for build, host
> > and target are genuinely different and so it's natural to associate the
> > environment with the board interface.
>
> This is getting somewhere: the framework would need to track distinct
> environment variables for (at minimum) build, host, and target *roles*, with
> additional issues that each *target* is likely to need its own environment
> settings and that the same box ("board") can potentially be used in all three
> roles. This is too complex to appear in the 1.6.4 release.
>
> > (The testsuite itself still needs
> > to manage temporary saves and restores in cases, typically native
> > compilers, where host and target are the same system and the environment
> > variables needed for target executables interfere with those for running
> > the compilers. This does occur for some GCC tests.)
>
> This last detail tells me that putting this in board_info is actually wrong,
> because the same board may need different environment overrides for different
> roles.
Tracking things in a separate variable (say env_info instead of
board_info) and then making remote_exec / remote_load extract the
overrides (based on whether "build", "host" or "target" is passed to
remote_*) and pass them down (together with any overrides that were
directly given to remote_load / remote_exec) doesn't particularly seem
more complicated than putting things in board_info, just different. It
could even use procedure names such as remote_pushenv as in my patch, or a
common remote_env, or something else.
It *does* need a way for a board to declare whether it has environment
variable support. There are tests currently skipped in the remote case
that should be skipped for a board lacking that support. But there are
also tests that just continue to run with best efforts - we don't want
executing everything on the host to fail because it doesn't know how to
set LC_ALL=C on that board, just because LC_ALL=C is used globally for
everything executed on the host, we want the tests to continue to run and
hope that in fact the board defaults to the C locale. So having
${board}_exec reject calls with environment variables when unsupported is
not a good solution - and remote_exec needs to take care to work with
existing board files that define ${board}_exec to take exactly five
arguments.
--
Joseph S. Myers
[email protected]
