Seen with --enable-maintainer-mode.
make[3]: *** No rule to make target '.../sim/ppc/Makefile.in', needed
by 'ppc/stamp-pk'. Stop.
* sim/ppc/local.mk (stamp-pk): Depend on local.mk not
Makefile.in.
* Makefile.in: Regenerate.
Approved-By: Tom Tromey <tom@tromey.com>
Some compilers warn in the frv code:
sem.c:24343:41: error: incompatible function pointer types passing
'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)')
to parameter of type
'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types]
This is due to frvbf_h_acc40U_set using UDI for setting the new value,
but using the common sim_queue_fn_di_write API which uses DI. The same
size, but different sign. We could change frvbf_h_acc40U_set to take a
DI without changing behavior in practice: the UDI is already passed via
the queue function which accepts a DI, and frvbf_h_acc40U_set already
casts the input to UDI before running any operations on it. However,
these files are all generated, so manual changes here would be reverted.
Seems like we can only change the register type for all APIs in the cpu
definition. This builds cleanly, and passes sim unittests. Not sure if
it's 100% the answer, but seems to be the best we have currently.
Bug: https://sourceware.org/PR29752
commit 1d506c26d9
Update copyright year range in header of all files managed by GDB
updated gnulib/Makefile.am but didn't regenerate gnulib/Makefile.in
also sim/Makefile.in was updated, but the Copyright hunks/years
were off. The first hunk comes from automake 1.15.1 header-vars.am
and so should have 2017 as last year, the second hunk does come from
sim/Makefile.am and so should have 2024 as last year.
* gnulib/Makefile.in: Regenerate.
* sim/Makefile.in: Likewise.
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
The HAVE_DECL_xxx defines are always defined to 0 or 1. The current
defines.h logic assumes every HAVE_xxx symbol is only defined iff it's
defined to 1 which causes this to break. Tweak the sed logic to only
match defines of 1.
Add support for compiling build tools with various -Werror settings.
Since the tools don't compile cleanly with the same set of flags as
the rest of the sim code, we need to maintain & test a separate list.
Only bother when not cross-compiling so we don't have to test all the
flags against the build compiler. This should be good enough for our
actual development flows.
The common igen code was forked from the ppc long ago. The filter
module is still pretty similar in API, so we can unfork them with
a little bit of effort.
The filter.c module is still here because of the unique it_is API.
The common igen code doesn't seem to have an equiv API as this only
operates on two strings and not an actual filter object, and it's
easy enough to leave behind to unfork the rest.
The common igen code was forked from the ppc long ago. The lf module
is still pretty similar in API, so we can unfork them with a little
bit of effort.
Some of the generated ppc code is now slightly different, but that's
because of fixes the common igen code has gained, but not the ppc igen
code (e.g. fixing of #line numbers).
The ppc code retains lf_print__c_code because the common igen code
rewrote the logic to a new table.c API. Let's delay that in the ppc
code to at least unfork all this code.
The common sim-endian is a forked & updated version of the ppc code.
Fortunately, they didn't diverge from the basic APIs, so they are
still compatible, which means we can just delete the ppc version now
that the build env is merged at the top-level.
The objects are still compiled in the subdir, but the creation of the
archive itself is in the top-level. This is a required step before we
can move compilation itself up, and makes it easier to review.
The downside is that each object compile is a recursive make instead of
a single one. It adds some overhead, so it's not great, but it shouldn't
be a big deal. This will go away once compilation is hoisted up.
Now that the ppc configure script is just namespaced options, we can
move it to ppc/acinclude.m4 and include it directly in the top-level
configure script and kill off the last subdir configure script.
The common igen code provides the same misc APIs as the ppc version,
so delete the ppc code and pull in the common one. There is one
minor difference: the ppc code has a unique dumpf function. The
common code switched to lf_printf for the same functionality, but
since that requires changes throughout the igen codebase, delay that
cleanup for now so we can merge the rest.
Now that both igen implementations are in the top-level, we can unify
the filter_filename implementation between them since they're the same
(literally the same code).
This simplifies the build a bit (especially for deps in port subdirs),
and avoids recursive make. This in turn speeds up the build, and lets
us reuse existing build-time vs host-time logic from Makefile.am.
The mloop files include CGEN generated switch files which have some
nested assignments that expand into repeated shadowed variables.
Fixing this looks fairly non-trivial as it appears to be interplay
between the common CGEN code and how this particular set of cris
insns are defined. Disable the warning instead.
In file included from sim/cris/mloop.in:286:
sim/cris/semcrisv10f-switch.c: In function ‘crisv10f_engine_run_full’:
sim/cris/semcrisv10f-switch.c:12383:8: error: declaration of ‘opval’ shadows a previous local [-Werror=shadow=local]
12383 | SI opval = tmp_addr;
| ^~~~~
sim/cris/semcrisv10f-switch.c:12371:9: note: shadowed declaration is here
12371 | USI opval = ({ SI tmp_addr;
| ^~~~~
And the code looks like:
USI opval = ({
...
{
SI opval = tmp_addr;
...
}
...
});
Since the CGEN code treats "opval" as an internal variable that the cpu
definitions don't have direct access to, the likelihood of this being a
real bug is low, so leave it be. The warning is suppressed for more code
that is hand written (e.g. the mloop logic), but disabling for the entire
file is the easiest way to suppress while keeping it on everywhere else in
the sim.
The generated mloop files can trigger compile time warnings. It can
be difficult to see/understand where the original code is coming from
as all the diagnostics point to the generated output. Using #line
pragmas, we can point people to the original source files.
Unfortunately, this code is written in POSIX shell, and that lacks
support for line number tracking. The $LINENO variable, even when
available, can just be plain wrong. For example, when using dash
and subshells, $LINENO can end up having negative values. Add a
wrapper script that will uses awk to rewrite the $LINENO variable
to the right value to avoid all that.
Basically lineno.sh takes an input script, rewrites all uses of
$LINENO into the actual line number (and $0 into the original file
name), and then executes the temporary script.
This commit doesn't actually add #line pragmas to any files. That
comes next.
Pull out the common parts of the genmloop invocation into the common
code. This will make it easier to add more, and make the per-port
differences a little more obvious.
Fix one minor pointer-sign warning to enable warnings in general
for this file. Reading the data as signed and then returning it
as unsigned should be functionally the same in this case.
The migration to local.mk in commit 0a129eb19a
accidentally listed the deps for all mloop steps as mloop.in instead of the
various variants that m32r uses.
Reported-by: Simon Marchi <simon.marchi@polymtl.ca>
We suppress the warning in the generated switch file because the cris
cpu file has a hack to workaround a cgen bug, but that generates a set
but unused variable which makes the compiler upset.
Reuse the bfd/development.sh script like most other project to
determine whether the current source tree is a dev build (e.g.
git) or a release build, and disable the warnings for releases.
This patch sets GUILE to just plain 'guile'.
In the distant ("devo") past, the top-level build did support building
Guile in-tree. However, I don't think this really works any more.
For one thing, there are no build dependencies on it, so there's no
guarantee it would actually be built before the uses.
This patch also removes the use of "-s" as an option to cgen scheme
scripts. With my latest patch upstream, this is no longer needed.
After the upstream changes, either Guile 2 or Guile 3 will work, with
or without the compiler enabled.
2023-08-24 Tom Tromey <tom@tromey.com>
* cgen.sh: Don't pass "-s" to cgen.
* Makefile.in: Rebuild.
* Makefile.am (GUILE): Simplify.
I saw this warning from make:
Makefile:5043: *** mixed implicit and normal rules: deprecated syntax
I believe this snuck in by error with the recent cgen-related changes.
This patch removes the stray '%' and rebuilds the Makefile.in. I'm
checking this in.
I had reason yesterday to want to regenerate configury files which I
do with --enable-maintainer-mode, and added --enable-cgen-maint
accidentally. The first problem I hit is that sim looks for cgen in a
different directory by default than opcodes, and I had my source
layout set up for opcodes rather than sim. Fix that by making both
use ../cgen first, then ../../cgen relative to sim/ and opcodes/. The
next problem was that various sim local.mk files expected generated
sources in the build dir rather than the source dir. Fix that by
adding $(srcdir) to paths. Finally, the generated iq2000 files had a
compile error, fixed by the cpu/iq2000.cpu patch.
cpu/
* iq2000.cpu (syscall): Add pc arg.
opcodes/
* configure.ac (cgendir): Default to ../../cgen, but use ../cgen
if found there.
* configure: Regenerate.
sim/m4/
* sim_ac_option_cgen_maint.m4 (cgendir): Look in ../cgen too.
sim/
* cris/local.mk: Add $(srcdir) to paths for regenerated source.
* frv/local.mk: Likewise.
* iq2000/local.mk: Likewise.
* lm32/local.mk: Likewise.
* m32r/local.mk: Likewise.
* or1k/local.mk: Likewise.
* Makefile.in: Regenerate.
* configure: Regenerate.
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.
Now that sim-main.h has been reduced significantly, we can remove it
from sim-signal.c and unify it across all boards since it compiles to
the same code.
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.
Add explicit arch-specific modules.c rules to keep the build from
generating an incorrect common/modules.c. Otherwise the pattern
rules would cascade such that it'd look for $arch/modules.o which
turned into common/modules.c which triggered the gen rule.
My local testing of this code didn't catch this bug because of how
Automake manages .Po (dependency files) in incremental builds -- it
was adding extra rules that override the pattern rules which caused
the build to generate correct modules.c files. But when building
from a cold cache, the pattern rules would force common/modules.c to
be used leading to crashes at runtime.
Now that all ports (that use igen) build in the top-level and depend
on igen, we can move the conditional logic out of configure. We also
switch from noinst_LIBRARIES to EXTRA_LIBRARIES so that the library
is only built when needed (i.e. the igen tool is used).
Now that all ports (other than ppc) build in the top-level, we don't
need to expand all the modules.c targets as a recursive dep. Each
port depends on their respective file now, and the ppc port doesn't
use it at all.
This makes sure the arch-specific modules.c wildcard is matched and
not the common/%.c so that we compile it correctly. It also makes
sure each subdir has depdir logic enabled.
Now that we build these objects in the top dir & generate modules.c
there, we don't need to generate them all first -- we can let the
normal dependency graph take care of building things in parallel.
This simplifies the build logic and avoids an Automake bug where the
common_libcommon_a_OBJECTS variable isn't set in the arch libsim.a
DEPENDENCIES for targets that, alphabetically, come before "common".
We aren't affected by that bug with the current code, but as we move
things out of SIM_ALL_RECURSIVE_DEPS and rely on finer dependencies,
we will trip over it.
Now that all ports (other than ppc) build in the top-level, we don't
need to mark the igen tool as a recursive dep. Each port depends on
the tool if it actually uses it, and ppc doesn't use it at all.
