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.
There's no need for these settings to be in sim-main.h which is shared
with common/ sim code, so move it all out to a new header which only
this port will include.
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.
We've been passing the environment strings to sim_create_inferior,
but most ports don't do anything with them. A few will use ad-hoc
logic to stuff the stack for user-mode programs, but that's it.
Let's formalize this across the board by storing the strings in the
normal sim state. This will allow (in future commits) supporting
more functionality in the run interface, and to unify some of the
libgloss syscalls.
We use the program argv to both find the program to run (argv[0]) and
to hold the arguments to the program. Most of the time this is fine,
but if we want to let programs specify argv[0] independently (which is
possible in standard *NIX programs), this double duty doesn't work.
So let's split the path to the program to run out into a separate
field by itself. This simplifies the various sim_open funcs too.
By itself, this code is more of a logical cleanup than something that
is super useful. But it will open up customization of argv[0] in a
follow up commit. Split the changes to make it easier to review.
The m4 macro has 2 args: the "wire" settings (which represents the
hardwired port behavior), and the default settings (which are used
if nothing else is specified). If none are specified, the arch is
expected to support both, and the value will be probed based on the
user runtime options or the input program.
Only two arches today set the default value (bpf & mips). We can
probably let this go as it only shows up in one scenario: the sim
is invoked, but with no inputs, and no user endian selection. This
means bpf will not behave like the other arches: an error is shown
and forces the user to make a choice. If an input program is used
though, we'll still switch the default to that. This allows us to
remove the WITH_DEFAULT_TARGET_BYTE_ORDER setting.
For the ports that set a "wire" endian, move it to the runtime init
of the respective sim_open calls. This allows us to change the
WITH_TARGET_BYTE_ORDER to purely a user-selected configure setting
if they want to force a specific endianness.
With all the endian logic moved to runtime selection, we can move
the configure call up to the common dir so we only process it once
across all ports.
The ppc arch was picking the wire endian based on the target used,
but since we weren't doing that for other biendian arches, we can
let this go too. We'll rely on the input selecting the endian, or
make the user decide.
Currently, the sim-config module will abort if alignment settings
haven't been specified by the port's configure.ac. This is a bit
weird when we've allowed SIM_AC_OPTION_ALIGNMENT to seem like it's
optional to use. Thus everyone invokes it.
There are 4 alignment settings, but really only 2 matters: strict
and nonstrict. The "mixed" setting is just the default ("unset"),
and "forced" isn't used directly by anyone (it's available as a
runtime option for some ports).
The m4 macro has 2 args: the "wire" settings (which represents the
hardwired port behavior), and the default settings (which are used
if nothing else is specified). If none are specified, then the
build won't work (see above as if SIM_AC_OPTION_ALIGNMENT wasn't
called). If default settings are provided, then that is used, but
we allow the user to override at runtime. Otherwise, the "wire"
settings are used and user runtime options to change are ignored.
Most ports specify a default, or set the "wire" to nonstrict. A
few set "wire" to strict, but it's not clear that's necessary as
it doesn't make the code behavior, by default, any different. It
might make things a little faster, but we should provide the user
the choice of the compromises to make: force a specific mode at
compile time for faster runtime, or allow the choice at runtime.
More likely it seems like an oversight when these ports were
initially created, and/or copied & pasted from existing ports.
With all that backstory, let's get to what this commit does.
First kill off the idea of a compile-time default alignment and
set it to nonstrict in the common code. For any ports that want
strict alignment by default, that code is moved to sim_open while
initializing the sim. That means WITH_DEFAULT_ALIGNMENT can be
completely removed.
Moving the default alignment to the runtime also allows removal
of setting the "wire" settings at configure time. Which allows
removing of all arguments to SIM_AC_OPTION_ALIGNMENT and moving
that call to common code.
The macro logic can be reworked to not pass WITH_ALIGNMENT as -D
CPPFLAG and instead move it to config.h.
All of these taken together mean we can hoist the macro up to the
top level and share it among all sims so behavior is consistent
among all the ports.
The defs.h header will take care of including the various config.h
headers. For now, it's just config.h, but we'll add more when we
integrate gnulib in.
This header should be used instead of config.h, and should be the
first include in every .c file. We won't rely on the old behavior
where we expected files to include the port's sim-main.h which then
includes the common sim-basics.h which then includes config.h. We
have a ton of code that includes things before sim-main.h, and it
sometimes needs to be that way. Creating a dedicated header avoids
the ordering mess and implicit inclusion that shows up otherwise.
The gdb/callback.h & gdb/remote-sim.h headers have nothing to do with
gdb and are really definitions for the libsim API under the sim/ tree.
While gdb uses those headers as a client, it's not specific to it. So
create a new sim/ namespace and move the headers there.
Provide a simple example simulator for people porting to new targets
to use as a reference. This one has the advantage of being used by
people and having a fun program available for it.
It doesn't require a special target -- the example simulators can be
built for any existing port.
