[PATCH 06/12] sim/testsuite: Support "requires: simoption <--name-of-option>"

[Hans-Peter Nilsson]

> Date: Wed, 16 Feb 2022 02:09:44 -0500
> From: Mike Frysinger <vapier@gentoo.org>

> On 16 Feb 2022 07:24, Hans-Peter Nilsson wrote:
> > Date: Tue, 15 Feb 2022 23:49:47 -0500 From: Mike Frysinger <vapier@gentoo.org>
> > > On 15 Feb 2022 00:03, Hans-Peter Nilsson via Gdb-patches wrote:
> > > > Simulator features can be present or not, typically
> > > > depending on different-valued configure options, like
> > > > --enable-sim-hardware[=off|=on].  To avoid failures in
> > > > test-suite-runs when testing such configurations, a new
> > > > predicate is needed, as neither "target", "progos" nor
> > > > "mach" fits cleanly.
> > > > 
> > > > The immediate need was to check for presence of a simulator
> > > > option, but rather than a specialized "requires-simoption:"
> > > > predicate I thought I'd handle the general (parametrized)
> > > > need, so here's a generic predicate machinery and a (first)
> > > > predicate to use together with it; checking whether a
> > > > particular option is supported, by looking at "run --help"
> > > > output.  This was inspired by the check_effective_target_
> > > > machinery in the gcc test-suite.
> > > 
> > > i really don't want --help to be an API surface like this.  it's the wrong
> > > layer for the job.
> > > 
> > > we have a sim_config_print function which dumps configuration information.
> > > i'd be fine making that the surface to build off of.  i don't think we
> > > print hardware there atm, but should be trivial to introduce.
> > > 
> > > only other missing piece is that it's not obvious how to access it from
> > > the CLI.  `run --version` doesn't include it.  `run --do-command version`
> > > does though :x.  i'd be amenable to improving this interface, either by a
> > > new option like --info-config</bikeshed> or some other route.
> > 
> > But, "run --version" is a check for the *option* to exist,
> > which exactly meets the need.  You describe a probe for a
> > particular *configuration*, which is arguably useful, but
> > not for checking whether a particular option is supported.
> 
> i think you misunderstand.

(Methinks it's the other way round.)

> you're basically running:
>   run --help | grep -e--option
> where --option is some functionality you care about.

Right, the option *needs to be supported*.  *How* it's
implemented is secondary.

> i'm saying --help is not an interface.  it should be free to change and
> reformat things as makes sense and not worry about
> testsuites breaking.

If that format happens, that'll be handled just like any
other change, with the test-suite adjusted.  It's not like
the --help output format changes very often.

The same argument can also be used for your proposed "run
--do-command version", which has actually changed in the
last 10 years, so I don't see this argument as for or
against anything.

> in the case of a multitarget binary, we probably wouldn't display all the
> options in a single page, but have arch-specific sections.

And sim_check_requires_simoption would then be altered to
filter-in the subtarget-specific section for the subtarget
being tested, no biggie.  I can also imagine that it may
happen without further action just by changing all "run" to
"run $subtarget" or $run_subtarget everywhere in the
test-suite if/when you go multitarget-binary.

> i'm proposing:
>   run --do-command version | grep <feature>
> where in this case you seem to care about hardware support being enabled.
> so the test would look like:
>   # requires: simoption WITH_HW

That would be fine (except for s/simoption/configoption/) if
I was actually testing something that was *necessarily*
linked to WITH_HW, and perhaps not even reflected in the
presence of a run-time simulator option.

Here, I'm testing the functionality of an option that just
*happens* to be linked to --enable/--disable-sim-hardware!
As you surely remember, it used to be a whole different
module.

To wit, my main point is that the test itself shouldn't have
to care about the implementation or dependent config
options; it should just mention the exact options that it
uses, when that presence may depend on something unknown
(perhaps something other than a configure-time option), just
as the current version does.

brgds, H-P