While mips has respected sim_igen_smp at configure time (which was
always empty since it defaulted smp to off), no other igen port did.
Move this to a makefile variable and plumb it through the common
IGEN_RUN variable instead so everyone gets it by default. We also
clean up some redundant -N0 setting with multirun mips.
All the runtimes were only initializing a single CPU. When SMP is
enabled, things quickly crash as none of the other CPU structs are
setup. Change the default from 0 to the compile time value.
This code fails to compile when SMP is enabled due to some obvious
errors. Fix those and change the logic to avoid CPP to prevent any
future rot from creeping back in.
Move this out of the global sim-main.h and to the few files that
actually use functions from it. Only the cgen ports were pulling
this, so this makes cgen & non-cgen behave more the same.
The cgen-types.h header sets up types that are needed by cgen-defs.h,
so move the include out of sim-main.h and to that header. It might
be needed in other specific modules, but for now let's kick it out of
sim-main.h to make some progress. Things still build with just this.
The bfd APIs are used only by sim-n-endian.h which is only included by
sim-endian.c, so move the bfd.h include there and out of sim-endian.h
which is included by many other modules.
Not all arches include this in sim-main.h, and the ones that do don't
actually use bfd defines in the sim-main.h header. Prune it to make
sim-main.h simpler so we can kill it off entirely in the future.
We add the include to the files that utilize e.g. bfd_vma though.
We've been using SIM_ADDR which has always been 32-bit. This means
the upper 32-bit address range in 64-bit sims is inaccessible. Use
64-bit addresses all the time since we want the APIs to be stable
regardless of the active arch backend (which can be 32 or 64-bit).
The length is also 64-bit because it's completely feasible to have
a program that is larger than 4 GiB in size/image/runtime. Forcing
the caller to manually chunk those accesses up into 4 GiB at a time
doesn't seem useful to anyone.
Bug: https://sourceware.org/PR7504
We need these in the top-level to generate libsim.a, but also in the
subdirs to generate hw-config.h. Move it to the local.mk, and pass
it down when running recursive make. This avoids duplication, and
makes it available to both. We can simplify this once we move the
various steps up to the top-level too.
In order to create libsim.a in the common dir, we need the list of
objects for each target. To avoid duplicating the list with the
recursive make in each port, pass it down as a variable. This is
a temporary hack until the top-level creates libsim.a for ports.
Now that all ports have migrated to the new framework, drop support
for the old sim_cpu_base layout. There's a lot of noise here, so
it's been split into a dedicated commit.
Currently all ports have to declare sim_cpu themselves in their
sim-main.h and then embed the common sim_cpu_base in it. This
dynamic makes it impossible to share common object code among
multiple ports because the core data structure is always different.
Let's invert this relationship: common code declares sim_cpu, and
the port uses the new arch_data field for its per-cpu state.
This is the first in a series of changes: it adds a define to select
between the old & new layouts, then converts all the ports that don't
need custom state over to the new layout. This includes mn10300 that,
while it defines custom fields in its cpu struct, never uses them.
The core device has an attach address method as the root of the tree
which calls out to the sim API. But it doesn't have a corresponding
detach method which means we just crash if anything tries to detach
itself from the core. In practice, the m68hc11 is the only model
that actually tries to detach itself on the fly, so no one noticed
earlier.
With this in place, we can delete the existing detach code from the
m68hc11 model since it defaults to "passthru" callback which will in
turn call the dv-core detach, and they have the same behavior -- call
the sim core API to detach from the address space.
Bug: https://sourceware.org/PR25211
Automake will run each subdir individually before moving on to the next
one. This means that the linking phase, a single threaded process, will
not run in parallel with anything else. When we have to link ~32 ports,
that's 32 link steps that don't take advantage of parallel systems. On
my really old 4-core system, this cuts a multi-target build from ~60 sec
to ~30 sec. We eventually want to move all compile+link steps to this
common dir anyways, so might as well move linking now for a nice speedup.
We use noinst_PROGRAMS instead of bin_PROGRAMS because we're taking care
of the install ourselves rather than letting automake process it.
We still have to maintain custom install rules due to how we rename
arch-specific files with an arch prefix in their name, but we can at
least unify the logic in the common dir.
This hasn't been used since the refactor way back in commit
f872d0d643968c1101bb8c07b252edd54f626da2 ("Only enable H/W
on some mips targets."), so punt it.
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.
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.
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.
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.
I see an uninitialized variable warning (with gcc 9.3.1) from
cgen-run.c, like this:
/tmp/build/sim/../../src/sim/cris/../common/cgen-run.c: In function ‘sim_resume’:
/tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:259:5: warning: ‘engine_fns$’ may be used uninitialized in this function [-Wmaybe-uninitialized]
259 | (* engine_fns[next_cpu_nr]) (cpu);
| ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/build/sim/../../src/sim/cris/../common/cgen-run.c:232:14: note: ‘engine_fns$’ was declared here
232 | ENGINE_FN *engine_fns[MAX_NR_PROCESSORS];
| ^~~~~~~~~~
This is a false positive - we over allocate engine_fn, and then only
initialize the nr_cpus entries which we will later go on to use.
However, we can easily silence this warning by initializing the unused
entries in engine_fns to NULL, this might also help if anyone ever
looks at engine_fns in a debugger, it should now be obvious which
entries are in use, and which are not.
With this change the warning is gone.
There should be no change in behaviour with this commit.
On the files generated by sim/common/genmloop.sh, variables pbb_br_type and
pbb_br_npc are declared uninitialized and passed to other functions in some
cases. Despite that those are harmless, they will generate GCC warnings
("-Wmaybe-uninitialized").
This commit ensures that pbb_br_type and pbb_br_npc variables are
initialized to a harmless value.
Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral"). On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).
To avoid this warning, this commit now uses vsnprintf to format error
message and pass the message to sim_engine_abort function with another
printf-style formatting.
This patch is mostly authored by Andrew Burgess and slightly modified by
Tsukasa OI.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Signed-off-by: Tsukasa OI <research_trasio@irq.a4lg.com>
Clang generates a warning if there is an ambiguous expression (possibly a
bitwise operation (& or |), but a logical operator (&& or ||) is used;
"-Wconstant-logical-operand"). On the default configuration, it causes a
build failure (unless "--disable-werror" is specified).
This is caused by predicate macros that use the form (base_variable & flag).
Clang considers them as regular integer values (not boolean) and
generates that warning.
This commit makes Clang think those predicate macros to be boolean.
Clang generates a warning if there is a redundant self-assignment
("-Wself-assign"). On the default configuration, it causes a build failure
(unless "--disable-werror" is specified).
This commit removes redundant self-assignments from two files.
Clang generates a warning if the format string of a printf-like function is
not a literal ("-Wformat-nonliteral"). On the default configuration, it
causes a build failure (unless "--disable-werror" is specified).
To avoid warnings on the printf-like wrapper, it requires proper
__attribute__((format)) and we have ATTRIBUTE_PRINTF macro for this reason.
This commit adds ATTRIBUTE_PRINTF to a printf-like function.
Like commit b82817674f, this replaces BFD_VMA_FMT "x" in sim/ with
PRIx64 and casts to promote bfd_vma to uint64_t. The one file using
BFD_VMA_FMT in gdb/ instead now uses hex_string, and a typo in the
warning message is fixed.
PTR will soon disappear from ansidecl.h. Remove uses in sim. Where
a PTR cast is used in assignment or function args to a void* I've
simply removed the unnecessary (in C) cast rather than replacing with
(void *).
In commit:
commit 60a3da00bd5407f07d64dff82a4dae98230dfaac
Date: Sat Jan 22 11:38:18 2022 +0000
objdump/opcodes: add syntax highlighting to disassembler output
I broke several sim/ targets by forgetting to update their uses of the
libopcodes disassembler to take account of the new styled printing.
These should all be fixed by this commit.
I've not tried to add actual styled output to the simulator traces,
instead, the styled print routines just ignore the style and print the
output unstyled.
This was left in subdirs because of the dynamic cgen usage. However,
we can move this breakpoint call to runtime and let gdb detect whether
the symbol exists.
