The verbose argument has always been an int treated as a bool, so
convert it to an explicit bool. Further, update the API docs to
match the reality that the verbose value is actually used by some
of the internal modules.
This has never been installed, and it's not clear anyone cares about
it in the local build dir (when the main program is sim/ppc/run), so
drop all the logic to simplify.
We have many uses of sys/stat.h that are unprotected by HAVE_SYS_STAT_H,
so this is more formalizing the reality that we require this header.
Since we switched to gnulib, it guarantees that a sys/stat.h exists
for us to include, so we're doubly OK.
We have many uses of unistd.h that are unprotected by HAVE_UNISTD_H,
so this is more formalizing the reality that we require this header.
Since we switched to gnulib, it guarantees that a unistd.h exists
for us to include, so we're doubly OK.
Those files have changed by regenerating using the maintainer mode.
The first line of sim/ppc/pk.h have changed by an effect of the commit
319e41e83a ("sim: ppc: inline the sim-packages option").
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.
Every file that igen outputs is then processed with the move-if-changed
shell script. This creates a lot of boilerplate in the build and not an
insignificant amount of build-time overhead. Move the simple "is the file
changed" logic into igen itself.
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
These headers define the register numbers for each port to implement
the sim_fetch_register & sim_store_register interfaces. While gdb
uses these, the APIs are part of the sim, not gdb. Move the headers
out of the gdb/ include namespace and into sim/ instead.
Simplify the build by moving the generation of these files from
build-time (via dgen.c that we have to compile & execute on the
build system) to maintainer/release mode (via spreg-gen.py that
we only ever execute when the spreg table actually changes). It
speeds up the build process and makes it easier for us to reason
about & review changes to the code generator.
The tool is renamed from "dgen" because it's hardcoded to only
generated spreg files. It isn't a generalized tool for creating
lookup tables.
To make it clear this is an input to the igen tool, rename it with an
igen extension. This matches the other files in the ppc dir (altivec
& e500 igen files), and the other igen ports (mips, mn10300, v850).
Nothing passes this to dgen, and even if it did, nothing would happen
because the generated spreg.[ch] files don't include any references
back to the original data table. So drop it to simplify.
Since we know we'll return 0 by default, we don't have to output case
statements for readonly or length fields whose values are also zero.
This is the most common case by far and thus generates a much smaller
switch table in the end.
Instead of writing:
case 1:
return 1;
case 2:
return 1;
...etc...
Output a single return so we get:
case 1:
case 2:
case ...
return 1;
This saves ~100 lines of code. Hopefully the compiler was already
smart enough to optimize to the same code, but if not, this probably
helps there too :).
This saves a single line for the same result. By itself, it's not
interesting, but we can further optimize the generated output and
completely omit the switch table in some cases. Which we'll do in
follow up commits.
This controls only one thing: how to call mkdir(). The gnulib code
already has a mkdir module that provides this exact logic for us, so
punt the code entirely.
This macro expansion was missing a set of outer-most parenthesis which
some compilers would complain about depending on how the macro is used.
This is just standard good macro hygiene too.
We've never run these helper programs directly. The igen program
includes the relevant source files directly and runs the code that
way. So stop wasting developer CPU time linking programs that are
never run. We leave the rules in place for people who need to test
and debug the specific bits of code every now & then.
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.
Nothing in the tree checks this option, or has checked for decades.
The pre-cvs-import ChangeLog suggests this was added & removed back
then, but can't be sure as that history doesn't exist in the VCS.
Nothing checks this define anywhere, so drop all the logic. We don't
want this to be a configure option in the first place as all such usage
should be automatic & following proper types.
This has only ever had a single option that's enabled by default.
The objects it adds are pretty small and don't add overhead at
runtime if it isn't used, so just enable it all the time to make
the build code simpler.
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.
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.
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/.
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.
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
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.
Because "%p" is the pointer conversion specifier to print a pointer in an
implementation-defined manner, the result with format string containing
"0x%p" can be strange. For instance, core_map_find_mapping prints error
containing "0x0x...." (processor is not NULL) or "0x(null)" (processor is
NULL) on glibc.
This commit replaces "0x%p" with "%p" to prevent unpredictable behavior.
After the recent series of fixes to mark more functions in the
simulator with ATTRIBUTE_PRINTF, there were some build failures in the
ppc sim due, in some cases, to bugs with the arguments being passed,
and in other cases, the issues were (maybe) less serious, with
arguments being the wrong size, or type, for the printf format being
used.
This commit fixes all of the issues that I ran into.
In each case I selected the easiest solution to the problem, which is
usually just casting the argument to the correct type. If anyone
later on thinks the print format should change, please feel free to do
that. What we have here should keep the simulator basically working
as it does currently, which is my goal with this commit.
