These manual settings were necessary when we weren't doing automatic
header dependency tracking. That was changed a while ago, and we use
automake now to do it all for us. As a result, many of these vars
aren't even referenced anymore.
Further, some of the source file generation (e.g. .c files, or igen,
or cgen outputs) were moved to the common automake build, and it takes
care of dependency tracking for us with the object files.
We have configure tests for this in the top-level configure script
to link this when necessary, so we don't need to explicitly list it
for specific ports.
With more C libraries moving functions entirely into the main -lc,
change the AC_CHECK_LIB calls to AC_SEARCH_LIBS so we look in there
first and avoid extra linkage when possible.
COMMON_LIBS is set to $(LIBS), and CONFIG_LIBS is set to that plus
@LIBS@. This leds to the values being used twice. Inline the
CONFIG_LIBS variable without @LIBS@ since it's used only once.
The top-level already sets up a libtool script for the host, so use
that when linking rather than invoking CC directly. This will also
happen when we (someday) move the building to pure automake.
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).
This is used to allow for dangling \ in object lists, but these are the
only ports that do it, and it isn't really necessary. Punt it to keep
the various makefiles harmonized.
The erc32 sim does a lot itself, including handling of the CLI. It
used to provide a run-compatible interface in the pre-nrun days, but
it was dropped when the old run interface was punted. Since the old
commit 465fb143c8 ("sim: make nrun the
default run program"), the erc32 run & sis programs have been the
same, and erc32 hasn't provide a real run-compatible interface.
Simplify this by linking the two programs via ln/cp instead of running
the linking phase twice to produce the same result. If/when we fix up
the erc32 port to have a proper run interface, it should be easy to
split these back apart into real programs.
Note: the interf.o reference in here is a bit of a misdirect. Since
that object is placed into libsim.a, it's never been linked into the
programs since the linker ignores objects that aren't referenced, and
only gdb uses those symbols.
The v850 port uses -DDEBUG to control whether to enable internal tracing.
We already have such options via the common trace framework, and those
can be controlled at build time via configure flags (which the v850 code
currently cannot). So switch it over to WITH_TRACE_ANY_P to simplify the
v850 build code even if it doesn't (yet) respect any other trace options.
Since all host files we compile use these settings, move them out of
libcommon.a and into the default AM_CPPFLAGS. This has the effect of
dropping the custom per-target automake rules. Currently it saves us
~150 lines, but since it's about ~8 lines per object, the overhead
will increase quite a bit as we merge more files into a single build.
This also changes the object output names, so we have to tweak the
rules that were pulling in the common objects when linking.
A bunch of these paths don't include any headers, and most likely
never will, so there's no real need to keep them. This will let
us harmonize paths with the top-level Makefile more easily, which
will in turn make it easier to move more compile steps there.
In order to merge more common/ files into the top-level, we need to
add more host flags to CPPFLAGS, and that conflicts with our current
use with build-time tools. So split them apart like we do with all
other build flags to avoid the issue.
When reading/writing arbitrary data to the system's memory, the unsigned
char pointer type doesn't make that much sense. Switch it to void so we
align a bit with standard C library read/write functions, and to avoid
having to sprinkle casts everywhere.
When reading/writing arbitrary data to the system's memory, the unsigned
char pointer type doesn't make that much sense. Switch it to void so we
align a bit with standard C library read/write functions, and to avoid
having to sprinkle casts everywhere.
Clang generates a warning if there is a function declaration/definition
with zero arguments. Such declarations/definitions without a prototype (an
argument list) are deprecated forms of indefinite arguments
("-Wdeprecated-non-prototype"). On the default configuration, it causes a
build failure (unless "--disable-werror" is specified).
But there is another issue. This function declaration in sim/sh/interp.c
is completely redundant. This commit just removes that declaration.
The variable "list" is only initialized when arg1 > 0 and when arg1 == 0,
an uninitialized value is passed to translate_endian_h2t function.
Although this behavior is harmless, this commit adds initialization to avoid
a GCC warning ("-Wmaybe-uninitialized").
Clang generates a warning if an argument is passed to a function without
prototype (zero arguments, even without (void)). Such calls are deprecated
forms of indefinite arguments passing ("-Wdeprecated-non-prototype").
On the default configuration, it (somehow) doesn't cause a build failure but
a warning is generated.
But because the cause is the same as the issue the author fixed in
"sim/erc32: Use int32_t as event callback argument", it would be better to
fix it now to prevent problems in the future.
To fix the issue, this commit makes struct irqcall to use int32_t as a
callback (callback) argument of an IRQ.
Clang generates a warning if an argument is passed to a function without
prototype (zero arguments, even without (void)). Such calls are deprecated
forms of indefinite arguments passing ("-Wdeprecated-non-prototype").
On the default configuration, it causes a build failure (unless
"--disable-werror" is specified).
To fix that, this commit makes struct evcell to use int32_t as a callback
(cfunc) argument of an event. int32_t is chosen because "event" function
accepts "int32_t arg".
Clang generates a warning if there is a function declaration/definition
with zero arguments. Such declarations/definitions without a prototype (an
argument list) are deprecated forms of indefinite arguments
("-Wdeprecated-non-prototype"). On the default configuration, it causes a
build failure (unless "--disable-werror" is specified).
This commit replaces () with (void) to avoid this warning.
Because of a Libiberty hack, getopt on GNU libc (2.25 or earlier) is
currently unusable on sim, causing a regression on CentOS 7.
This is caused as follows:
1. If HAVE_DECL_GETOPT is defined (getopt declaration with known prototype
is detected while configuration), a declaration of getopt in
"include/getopt.h" is suppressed.
The author started to define HAVE_DECL_GETOPT in sim with the commit
340aa4f687 ("sim: Check known getopt definition existence").
2. GNU libc (2.25 or earlier)'s <unistd.h> includes <getopt.h> with a
special purpose macro defined to declare only getopt function but due
to include path (not tested while configuration), it causes <unistd.h>
to include Libiberty's "include/getopt.h".
3. If both 1. and 2. are satisfied, despite that <unistd.h> tries to
declare getopt by including <getopt.h>, "include/getopt.h" does not do
so, causing getopt function undeclared.
Getting rid of "include/getopt.h" (e.g. renaming this header file) is the
best solution to avoid hacking but as a short-term solution, this commit
replaces getopt with getopt_long under sim/.
Zero initialize engine_fns entirely at creation, then override those
fields we intend to use, rather than zero just initializing the unused
fields later on.
There should be no user visible changes after this commit.
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.
In the lm32 simulator, I was seeing some warnings about missing
function declarations.
The lm32 simulator has a weird header structure, in order to pull in
the full cpu.h header we need to define WANT_CPU_LM32BF. This is done
in some files, but not in others. Critically, it's not done in some
files that then use functions declared in cpu.h
In this commit I added the missing #define so that the full cpu.h can
be included.
After doing this there are still a few functions that are used
undeclared, these functions appear to be missing any declarations at
all, so I've added some to cpu.h.
With this done all the warnings when compiling lm32 are resolved for
both gcc and clang, so I've removed the SIM_WERROR_CFLAGS line from
Makefile.in, this allows lm32 to build with -Werror.
There are two places in the h8300 simulator where we assign a variable
to itself. Clang gives a warning for this, which is converted into an
error by -Werror.
Silence the warning by removing the self assignments. As these
assignments were in a complex if/then/else tree, rather than try to
adjust all the conditions, I've just replaced the self assignments
with a comment and an empty statement.
In the ppc simulator, clang was warning about some code like this:
busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P(out_vmask)) ? 1 : 2;
The warning was:
operator '?:' has lower precedence than '+'; '+' will be evaluated first
I suspect that this is not the original authors intention.
PPC_ONE_BIT_SET_P is going to be 0 or 1, so if we evaluate the '+'
first, the condition will always be non-zero, so true. The whole
expression could then be simplified to just '1', which doesn't make
much sense.
I suspect the answer the author was expecting was either 2 or 3. Why
they didn't just write:
busy_ptr->nr_writebacks = (PPC_ONE_BIT_SET_P(out_vmask)) ? 2 : 3;
I have no clue, however, to keep the structure of the code unchanged,
I've updated things to:
busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P (out_vmask) ? 1 : 2);
which silences the warning from clang, and is, I am guessing, what the
original author intended.
In the ppc simulator's do_fstat function, which provides the fstat
call for the simulator, if the fstat is going to fail then we
currently write an uninitialized buffer into the simulated target.
In theory, I think this is fine, we also write the error status into
the simulated target, so, given that the fstat has failed, the target
shouldn't be relying on the buffer contents.
However, writing an uninitialized buffer means we might leak simulator
private data into the simulated target, which is probably a bad thing.
Plus it probably makes life easier if something consistent, like all
zeros, is written rather than random junk, which might look like a
successful call (except for the error code).
So, in this commit, I initialize the stat buffer to zero before
it is potentially used. If the stat call is not made then the buffer
will be left initialized as all zeros.
The ppc simulator, in sim_create_inferior, tries to print the function
local entry_point variable before the variable is initialized.
In this commit, I defer the debug print line until the variable has
been initialized.
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
These configure scripts check $target and change behavior. They
shouldn't be doing that, but until we can rework the sim to change
behavior based on the input ELF, restore AC_CANONICAL_SYSTEM to
these so that $target is correctly populated.
This was lost in the d3562f83a7
("sim: unify toolchain probing logic") refactor as the logic was
hoisted up to the common code. But the fact the vars weren't
passed down to the sub-configure scripts was missed.
Bug: https://sourceware.org/PR29439
Not only that sim/configure.ac does not AC_SUBST CXXFLAGS,
unless we need C++ compiler like CXX, substitution @CXXFLAGS@ is useless.
Because of this, this commit removes this substitution.
When building the iq2000 simulator I see a few warnings like this:
/tmp/build/sim/../../src/sim/iq2000/iq2000.c: In function ‘fetch_str’:
/tmp/build/sim/../../src/sim/iq2000/iq2000.c:50:54: error: pointer targets in passing argument 3 of ‘sim_read’ differ in signedness [-Werror=pointer-sign]
50 | sim_read (CPU_STATE (current_cpu), CPU2DATA(addr), buf, nr);
| ^~~
| |
| char *
I've silenced these warnings by casting buf to 'unsigned char *'.
With this change I now see no warnings when compiling iq2000.c, so
I've removed the line from Makefile.in that disables -Werror.
Makefile.in was also disabling -Werror when compiling mloop.c,
however, I'm not seeing any warnings when compiling that file, so I've
removed the -Werror disable in that case too.
When building the erc32 simulator I get a few warnings like this:
/tmp/build/sim/../../src/sim/erc32/exec.c:1377:21: warning: dereferencing type-punned pointer will break strict-aliasing rules [-Wstrict-aliasing]
1377 | sregs->fs[rd] = *((float32 *) & ddata[0]);
| ~^~~~~~~~~~~~~~~~~~~~~~~
The type of '& ddata[0]' will be 'uint32_t *', which is what triggers
the warning.
This commit makes use of memcpy when performing the type-punning,
which resolves the above warnings.
With this change, I now see no warnings when compiling exec.c, which
means that the line in Makefile.in that disables -Werror can be
removed.
There should be no change in behaviour after this commit.
The device_error function always ends up calling the error function,
which is itself marked as ATTRIBUTE_NORETURN, so it makes sense that
device_error should also be marked ATTRIBUTE_NORETURN.
Doing this resolves a few warnings from hw_ide.c about possibly
uninitialized variables - the variables are only uninitialized after
passing through a call to device_error, which obviously means the
variables are never really used uninitialized, the simulation will
terminate with the device_error call.
This commit is a follow on to:
commit 182421c9d2
Date: Tue Oct 11 15:02:08 2022 +0100
sim/ppc: fixes for arguments to printf style functions
where commit 182421c9d2 addressed issues with printf format
arguments that were causing the compiler to give an error, this commit
addresses issues that caused the compiler to emit a warning.
This commit is mostly either changing the format string to match the
argument, or in some cases, excess, unused arguments are removed.
