The BPF port in binutils has been rewritten (commit
d218e7fedc) in order to not be longer
based on CGEN. Please see that commit log for more information.
This patch updates the BPF simulator accordingly. The new
implementation is much simpler and it is based on the new BPF opcodes.
Tested with target bpf-unknown-none with both 64-bit little-endian
host and 32-bit little-endian host.
Note that I have not tested in a big-endian host yet. I will do so
once this lands upstream so I can use the GCC compiler farm.
On a bpf-*-* testsuite fails:
./ld/ld-new: warning: test has a LOAD segment with RWX permissions
Adjusting `--memory-size=10Mb' to the simulator bpf testsuite passes.
Tested on bpf-*-*:
Bug: https://sourceware.org/PR29954
sim/testsuite:
* bpf/allinsn.exp (SIMFLAGS_FOR_TARGET): Adjust sim flags.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
If the counter for LOOP instruction is provided by a register with
value zero, then the instruction must cause a PC jump directly to the
loop end. But in that particular case simulator must not initialize
its internal loop variables, because loop body will not be executed.
Instead, simulator must obtain the loop's end address directly from
the LOOP instruction.
Signed-off-by: Dimitar Dimitrov <dimitar@dinux.eu>
This test uses the test itself as an input to stating regular files.
This gets funky though: when we run check in parallel, the output
object dir is the subdir that matches the .exp file. When we run
with -j1, the output object dir is the sim builddir itself.
The old test would append argv[0] to find the file, while the new
test uses basename on it. Each method works in only one of the
aforementioned build scenarios. Rather than complicate this any
more, switch to a different file that we know will always exist:
the Makefile.
This test assumes that /bin/sh will never be a CRIS ELF by way of
assuming that the current bfd cannot load it (since a basic cris
cross-compiler only understands CRIS ELFs). In a multi-target
build though, bfd understands just about every ELF out there, so
we're able to read the /bin/sh format before failing at a diff
point in the cris code.
Let's switch to using / instead since it'll fail for a similar
reason (at least similar enough for what this test is testing).
The current logic limits itself to a maxdepth of 4 when looking for
results. This wouldn't be a problem if cris didn't have a testsuite
at a depth of 5 which we end up ignoring when summarizing. Rather
than bump the number from 4 to 5, rework the code so that we gather
the exact set of tests that we tried to run.
Now that we run `check/foo.exp` instead of `check/./foo.exp`,
update the config/ & lib/ exceptions to cover both paths.
Bug: https://sourceware.org/PR29596
Make sure we invoke runtest with the same exp filenames when running in
parallel as it will find when run single threaded. When `runtest` finds
files itself, it will use paths like "aarch64/allinsn.exp". When we run
`find .` with the %p option, it produces "./aarch64/allinsn.exp". Switch
to %P to get "aarch64/allinsn.exp".
Bug: https://sourceware.org/PR29596
After this commit:
commit 0938b032da
Date: Wed Feb 2 10:06:15 2022 +0900
RISC-V: Add 'Zmmul' extension in assembler.
some instructions in the RISC-V simulator stopped working as a new
instruction class 'INSN_CLASS_ZMMUL' was added, and some existing
instructions were moved into this class.
The simulator doesn't currently handle this instruction class, and so
the instructions will now cause an illegal instruction trap.
This commit adds support for INSN_CLASS_ZMMUL, and adds a test that
ensures the affected instructions can be executed by the simulator.
Reviewed-by: Palmer Dabbelt <palmer@rivosinc.com>
Reviewed-by: Andrew Burgess <aburgess@redhat.com>
This is the last of the correctness fixes I've been carrying around for the
v850.
Like the other recent fixes, this is another case where we haven't been as
careful as we should WRT host vs target types. For the divq instruction
both operands are 32 bit types. Yet in the simulator code we convert them
from unsigned int to signed long by assignment. So 0xfffffffb (aka -5)
turns into 4294967291 and naturally that changes the result of our division.
The fix is simple, insert a cast to int32_t to force interpretation as a
signed value.
Testcase for the simulator is included. It has a trivial dependency on the
bins patch.
I've been carrying this for a few years. One test in the GCC testsuite is
failing due to a bug in the handling of the v850e3v5 instruction "bins".
When the "bins" instruction specifies a 32bit bitfield size, the simulator
exhibits undefined behavior by trying to shift a 32 bit quantity by 32 bits.
In the case of a 32 bit shift, we know what the resultant mask should be. So
we can just set it.
That seemed better than using 1UL for the constant (on a 32bit host unsigned
long might still just be 32 bits) or needlessly forcing everything to
long long types.
Thankfully the case where this shows up is only bins <src>, 0, 32, <dest>
which would normally be encoded as a simple move.
* testsuite/v850/allinsns.exp: Add v850e3v5.
* testsuite/v850/bins.cgs: New test.
* v850/simops.c (v850_bins): Avoid undefined behavior on left shift.
There was an omission on 3e6dc39ed7 "sim/testsuite: Set
global_cc_os also when no compiler is found"; global_cc_os
wasn't set for other than the primary target, which means
that the "unguarded" use of global_cc_os in
testsuite/cris/c/c.exp caused the dreaded "ERROR: can't read
"global_cc_os": no such variable" when e.g. configuring for
pru-elf and doing "make check-sim". Better initializing
both variables at the top to default values, rather than
adding another single 'set global_cc_os ""', to reduce the
risk of not setting them properly if or when that
if-statement-chain is made longer.
sim/testsuite:
* lib/sim-defs.exp (sim_init_toolchain): Default
global_cc_os and global_cc_works properly, before if-chain.
...when we know we have a working compiler. This will reduce
the risk of faulty edits by exposing them rather than hiding
them as "unresolved". It also harmonizes behavior with that of
run_sim_test.
* c/c.exp: Mark C tests failing compilation test errors.
Calls to basename were added here as part of commit
e1e1ae6e9b "sim: testsuite: fix objdir handling", but that
commit missed adding "#include <libgen.h>" or the equivalent
GNU extension, see basename(3). Fixing that shows a logical
error in the change to openpf1.c; the non-/-prefixed
code-path was changed instead of the "/"-prefixed code-path,
which is the one executed after that commit.
For "newlib" these tests failed linking after that commit.
Recent newlib has the (asm-renamed) GNU-extension-variant of
basename, but we're better off not using it at all.
Unfortunately, compilation failures for C tests run by the
machinery in c.exp are currently just marked "unresolved",
in contrast to C and assembler tests run by calling
run_sim_test.
The interaction of calling with the full program-path vs.
use of --sysroot exposes a consistency problem: when
--sysroot is used, argv[0] isn't the path by which the
program can find itself. It's undecided whether argv[0] for
the program running in the simulator should be edited
(related to the naked argument to the simulator before
passing on to the simulated program) to remove a leading
--sysroot. Either way, such a change would be out of scope
for this commit.
* c/stat3.c (mybasename): New macro. Use it instead of basename.
* c/openpf1.c: Correct basename-related change and update related
comment.
Apply the new run_sim_test option "require" as in "#require
simoption --cris-900000xx" for all tests using that option.
This allows a clean test-suite-run for a build with
--disable-sim-hardware, where that option is not supported,
by skipping those tests as "untested".
sim/testsuite/cris:
* asm/io1.ms, asm/io2.ms, asm/io3.ms, asm/io6.ms,
asm/io7.ms: Call "#require: simoption --cris-900000xx".
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.
Multiple "requires: <requirement> <parameter>" form a list of
predicates (with parameters), to be used as a conjunction.
sim/testsuite:
* lib/sim-defs.exp (sim_check_requires_simoption): New function.
(run_sim_test): Support "requires: <requirement> <parameter>".
For reasons that remain largely to be investigated (besides
the apparent lack of synchronization between two processes),
this test fails randomly, with two different sets of common
outputs. Curiously, that doesn't happen for the other
similar tests. There's a comment that mentions this, though
that doesn't make it a sustainable part of a test-suite.
(Known-blinking tests should be disabled until fixed.)
sim/testsuite/cris:
* hw/rv-n-cris/irq1.ms: Disable by use of a never-matched
"progos" value.
Commit a39487c668 "sim: cris: use -sim with C tests for cris-elf
targets" caused " -sim" to be appended to CFLAGS_FOR_TARGET for
cris*-*-elf, where testing had until then relied on
"RUNTESTFLAGS=--target_board=cris-sim" being passed when running "make
check-sim", adding the right options. While "-sim" happens to work,
the baseboard-file cris-sim.exp uses "-sim3" so for consistency use
that instead.
Then commit b42f20d2ac "sim: testsuite: drop most specific istarget
checks" caused " -sim" to be appended for *all* targets, which just
doesn't work. For example, for crisv32-linux-gnu, that's not a
recognized option and will cause a dejagnu error and further testing
in c.exp will be aborted.
While cris-sim.exp appends "-static" for *-linux-gnu, further changes
in the test-suite have caused "linux"-specific tests to break, so that
part will be tended to separately.
But, save and restore CFLAGS_FOR_TARGET around the modification and
use where needed, to not have the CRIS-specific modification affect a
continuing test-run (possibly for other targets).
sim/testsuite/cris:
* c/c.exp (CFLAGS_FOR_TARGET): Replace appended option " -sim"
with " -sim3", but do it conditionally for newlib targets. Save
and restore CFLAGS_FOR_TARGET in saved_CFLAGS_FOR_TARGET such
that it doesn't affect the value of CFLAGS_FOR_TARGET outside
c.exp.
If we don't set this variable, it doesn't exist, and using "#progos:"
in an assembler-file will cause an error rather than just skipping the
test, viz:
Running /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp ...
ERROR: tcl error sourcing /src/sim/testsuite/cris/hw/rv-n-cris/rvc.exp.
ERROR: can't read "global_cc_os": no such variable
while executing
"if { $opts(progos) != "" && $opts(progos) != $global_cc_os } {
untested $subdir/$name
return
}"
(procedure "run_sim_test" line 102)
Neither the commit introducing progos, nor the top comment
in run_sim_test, mentions progos as intended only for C
tests, or that its use must be gated on $global_cc_works !=
0, so (not) setting it in the no-working-compiler path seems
just overlooked.
Allowing it to be used for assembler tests makes it usable
for e.g. an always-false predicate and in expressions in
.exp files without gating on $global_cc_works != 0.
With this patch, global_cc_os is set to "", just as for "unknown OS".
sim/testsuite:
* lib/sim-defs.exp (sim_init_toolchain): Set global_cc_os also when
no working target C compiler is found.
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
The ## marker tells automake to not include the comment in its
generated output, so use that in most places where the comment
only makes sense in the inputs.
Running frv's allinsn in serial is quite slow due to the sheer number
of tests it contains. By splitting it up and running in parallel, the
execution time on my system goes from ~100sec to ~60sec.
We'll rely on the toolchain probing to determine whether each arch's
tests can be run rather the current configure target. This allows
testing all of the ports in a multitarget configuration.
For now, we don't reformat the files entirely to make it easier to
review, and in case we need to make adjustments. Once this feels
like it's stable, we can flatten the code a bit by removing the if
statement entirely.
Break up the dejagnu logic so that we can parallelize the testsuite.
This takes a page from gcc & gdb where each .exp is run in isolation
instead of in serial.
For most targets, this doesn't make much of a difference as they only
have a single .exp. A few (like cris & frv) have multiple .exp though
and will see a bit of a speed up.
The real gain is when testing a multitarget build. This way we can
run all the targets in parallel and cut the execution time a bit.
On my system, it goes from ~155sec to ~100sec.
We can gain further speedups by splitting up some of the larger .exp
files into smaller groups. We'll do that in a followup though.
Leverage the new per-port toolchain settings to initialize the env
for eeach set of tests. This allows us to run all the tests in a
multitarget build if the user sets up the vars. If they don't, we
can still skip all the tests.
Gas does not support multitarget builds -- it still only supports
a single input & output format. ld is a bit better, but requires
manual flags to select the right output. This makes it impossible
to run the complete testsuite in a multitarget build.
To address this limitation, create a suite of FOR_TARGET variables
so these can be set to precompiled as & ld programs. It requires
a bit of setup ahead of time, but it's a one-time cost, and makes
running the full testsuite at once much easier.
As we setup more reliable CC_FOR_TARGET variables for each target, the
bfin way of overriding it to stuff custom CFLAGS doesn't scale well.
Add a dedicated CFLAGS_FOR_TARGET_init setting that each set of tests
can setup if they want to add custom options.
If the board info sets the sim to a basename that is found via $PATH
(which is the default dejagnu behavior), the logic here to use its
dirname to find rvdummy fails because it looks for `./rvdummy`. So
switch it to always use the local build of rvdummy which is the one
we want to be testing against in the first place.
If we get a request for testing against a different setup, we can
figure out & document the needs at that point, and then setup some
config knobs to control it.
Add missing $(EXEEXT) to dependencies on bits-gen. These are actually
build-only tools, but automake doesn't allow for build & host tools, so
the rules are re-using EXEEXT.
We usually test against the newlib/libgloss environment, but for a
few ports that also support Linux apps, we want to test that logic
too. A lot of the C code is written such that it works with either
newlib/libgloss or glibc/linux toolchains, but we have some tests
that end up being Linux-specific. Cris has been using the target
tuple as a rough proxy for this (where cris*-*-elf is assumed to be
newlib/libgloss, and everything else is glibc/linux), but that is a
bit too rough, and it doesn't work in a multitarget build.
So lets create a few stub files that we can do compile tests with
to detect the different setups, and then let tests declare which
one they require (if they require any at all).
Both bfin & cris ports test the C compiler to see if it works, but in
their own way. Unify the checks in the common code so we can leverage
them in more ports in the future, and collapse the bfin & cris code.
The sim_init function was called by runtest for each test when --tool
was set to sim. When we changed to --tool '' to collapse the testsuite
dir, the init function was no longer called on every test. However, it
was still being called explicitly by config/default.exp. It's not clear
why that explicit call ever existed since, in the past, it meant it was
redundant.
Lets drop the single sim_init call in config/default.exp and move it out
to all our tests. This replicates the runtest behavior so we can setup
variables on a per-test basis which allows us to recollapse the sim_path
logic back. We'll also leverage this in the future for toolchain setup.
Also add a few comments clarifying the overall runtime behavior.
If the cris sim hasn't been built yet, trying to run its testsuite
will hang indefinitely. The common sim APIs already have this, so
copy it over to the cris forks of the test+run functions.
The tests assume that the cwd is the objdir directory and write its
intermediates to there all the time. When using runtest's --objdir
setting though, this puts the files in the wrong place. This isn't
a big problem currently as we never change --objdir, but in order to
support parallel test execution, we're going to start setting that
option, so clean up the code ahead of time.
We also have to tweak some of the cris tests which were making
assumptions about the argv[0] value.
Now that all the other toolchain settings have been renamed to match
the dejagnu settings of XXX_FOR_TARGET, rename global_sim_options to
SIMFLAGS_FOR_TARGET too.
Only a few tests actually use global_ld_options, but we can replace the
sim-specific settings with the dejagnu common LDFLAGS_FOR_TARGET and get
the same result.
Only a few tests actually use global_as_options, but we can replace the
sim-specific settings with the dejagnu common ASFLAGS_FOR_TARGET and get
the same result.
Nothing in the testsuite is using this setting, so let's drop it.
Any code that wants to set compiler flags can use CFLAGS_FOR_TARGET
instead to get the same effect.
These haven't been used in over 20 years. The sim testsuite used to
run these tools itself directly, but back in ~1999 it switched to the
dejagnu helpers (e.g. target_assemble & target_link), and the dejagnu
logic only utilizes XXX_FOR_TARGET variables. Punt them here to avoid
confusion with dead code.
The v850 testsuite code has been testing the $opt variable, but this
was never actually set anywhere globally or v850-specific. Instead,
this was a random variable leaking out of the sh testsuite code. As
far as I can tell, it has always been this way. That means the code
only ever tested the v850 cpu target (which is the default).
This failure can be easily seen in practice by running the v850 code
in isolation and seeing it crash:
$ runtest v850/allinsns.exp
...
Running target unix
Using /usr/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /usr/share/dejagnu/config/unix.exp as generic interface file for target.
Using ../../../sim/testsuite/config/default.exp as tool-and-target-specific interface file.
WARNING: Assuming target board is the local machine (which is probably wrong).
You may need to set your DEJAGNU environment variable.
Running ../../../sim/testsuite/v850/allinsns.exp ...
ERROR: tcl error sourcing ../../../sim/testsuite/v850/allinsns.exp.
ERROR: tcl error code TCL LOOKUP VARNAME opt
ERROR: can't read "opt": no such variable
while executing
"switch -regexp -- $opt {
Backing up a bit, the reason for this logic in the first place is
because the common sim testsuite code makes an assumption about the
assembler options with cpu_option -- the option and its value are
always separated by an =. This is not the case with v850. So tweak
the core sim logic a bit to support omitting the = so that we can
switch v850 to the standard all_machs setting and avoid opt entirely.
