mirrors/binutils-gdb
0
0
Fork 0
mirror of https://sourceware.org/git/binutils-gdb.git synced 2024-12-12 20:03:45 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
1fb5ccd6bf
binutils-gdb/sim/frv/local.mk

112 lines
3.2 KiB
Makefile
Raw Normal View History

sim: use ## for automake comments The ## marker tells automake to not include the comment in its generated output, so use that in most places where the comment only makes sense in the inputs.
2021-12-09 14:40:28 +08:00
## See sim/Makefile.am
##
Update copyright year range in header of all files managed by GDB 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.
2024-01-12 23:30:44 +08:00
## Copyright (C) 1998-2024 Free Software Foundation, Inc.
sim: use ## for automake comments The ## marker tells automake to not include the comment in its generated output, so use that in most places where the comment only makes sense in the inputs.
2021-12-09 14:40:28 +08:00
## Contributed by Red Hat.
##
## This program is free software; you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation; either version 3 of the License, or
## (at your option) any later version.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program. If not, see <http://www.gnu.org/licenses/>.
sim: hoist cgen mloop rules up to common builds These rules don't depend on the target compiler settings, so hoist the build logic up to the common builds for better parallelization. We have to extend the genmloop.sh logic a bit to allow outputting to a subdir since it always assumed cwd was the right place. We leave the cgen maintainer rules in the subdirs for now as they aren't normally run, and they rely on cgen logic that has not yet been generalized.
2021-10-31 15:29:36 +08:00
sim: frv: move arch-specific file compilation to top-level The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-02 02:43:06 +08:00
AM_CPPFLAGS_%C% = $(SIM_FRV_TRAPDUMP_FLAGS)
sim: common: move modules.c to source tracking 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.
2023-01-03 05:46:14 +08:00
nodist_%C%_libsim_a_SOURCES = \
%D%/modules.c
sim: common: move libcommon.a objects to sources 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.
2023-01-03 03:15:02 +08:00
%C%_libsim_a_SOURCES = \
$(common_libcommon_a_SOURCES)
sim: frv: move libsim.a creation to 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. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2022-12-27 10:28:10 +08:00
%C%_libsim_a_LIBADD = \
$(patsubst %,%D%/%,$(SIM_NEW_COMMON_OBJS)) \
$(patsubst %,%D%/dv-%.o,$(SIM_HW_DEVICES)) \
\
%D%/cgen-accfp.o \
%D%/cgen-fpu.o \
%D%/cgen-run.o \
%D%/cgen-scache.o \
%D%/cgen-trace.o \
%D%/cgen-utils.o \
\
%D%/arch.o \
%D%/cgen-par.o \
%D%/cpu.o \
%D%/decode.o \
%D%/frv.o \
%D%/mloop.o \
%D%/model.o \
%D%/sem.o \
\
%D%/cache.o \
%D%/interrupts.o \
%D%/memory.o \
%D%/options.o \
%D%/pipeline.o \
%D%/profile.o \
%D%/profile-fr400.o \
%D%/profile-fr450.o \
%D%/profile-fr500.o \
%D%/profile-fr550.o \
%D%/registers.o \
%D%/reset.o \
%D%/sim-if.o \
%D%/traps.o
$(%C%_libsim_a_OBJECTS) $(%C%_libsim_a_LIBADD): %D%/hw-config.h
noinst_LIBRARIES += %D%/libsim.a
sim: modules.c: fix generation after recent refactors 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.
2023-01-16 09:48:28 +08:00
## Override wildcards that trigger common/modules.c to be (incorrectly) used.
%D%/modules.o: %D%/modules.c
sim: move arch-specific file compilation of common/ files to top-level
2023-01-02 03:55:09 +08:00
%D%/%.o: common/%.c ; $(SIM_COMPILE)
-@am__include@ %D%/$(DEPDIR)/*.Po
sim: frv: move libsim.a creation to 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. On my 4 core system, it adds ~100msec to the build per port, so it's not great, but it shouldn't be a big deal. This will go away of course once the top-level compiles objects.
2022-12-27 10:28:10 +08:00
sim: run: move linking into top-level 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.
2022-11-03 19:19:13 +08:00
%C%_run_SOURCES =
%C%_run_LDADD = \
%D%/nrun.o \
%D%/libsim.a \
$(SIM_COMMON_LIBS)
noinst_PROGRAMS += %D%/run
sim: install various doc files
2021-11-19 08:32:31 +08:00
%C%docdir = $(docdir)/%C%
%C%doc_DATA = %D%/README
sim: build: move generated headers to built sources Automake's automatic header deptracking has a bootstrap problem where it can't detect generated headers when compiling. We've been handling that by adding a custom SIM_ALL_RECURSIVE_DEPS variable, but that only works when building objects recursively in subdirs. As we move those out to the top-level, we don't have any recursive steps anymore. The Automake approach is to declare those headers in BUILT_SOURCES. This isn't completely foolproof as the Automake manual documents: it only activates for `make all`, not `make foo.o`, but that shouldn't be a huge limitation as it only affects the initial compile. After that, rebuilds should work fine.
2023-01-03 10:16:19 +08:00
## List all generated headers to help Automake dependency tracking.
BUILT_SOURCES += %D%/eng.h
sim: hoist cgen mloop rules up to common builds These rules don't depend on the target compiler settings, so hoist the build logic up to the common builds for better parallelization. We have to extend the genmloop.sh logic a bit to allow outputting to a subdir since it always assumed cwd was the right place. We leave the cgen maintainer rules in the subdirs for now as they aren't normally run, and they rely on cgen logic that has not yet been generalized.
2021-10-31 15:29:36 +08:00
%C%_BUILD_OUTPUTS = \
%D%/mloop.c \
%D%/stamp-mloop
sim: build: drop most recursive build deps 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.
2023-01-03 03:34:52 +08:00
## Generating modules.c requires all sources to scan.
sim: modules: trigger generation from top-level Add rules for tracking generated subdir modules.c files. This doesn't actually generate the file from the top-level, but allows us to add rules that need to be ordered wrt it. Once those changes land, we can rework this to actually generate from the top-level. This currently builds off of the objects that go into the libsim.a as we don't build those from the top-level either. Once we migrate that up, we can switch this to the source files directly. It's a bit hacky overall, but makes it easier to migrate things in smaller chunks, and we aren't going to keep this logic long term.
2022-12-26 03:40:47 +08:00
%D%/modules.c: | $(%C%_BUILD_OUTPUTS)
sim: hoist cgen mloop rules up to common builds These rules don't depend on the target compiler settings, so hoist the build logic up to the common builds for better parallelization. We have to extend the genmloop.sh logic a bit to allow outputting to a subdir since it always assumed cwd was the right place. We leave the cgen maintainer rules in the subdirs for now as they aren't normally run, and they rely on cgen logic that has not yet been generalized.
2021-10-31 15:29:36 +08:00
sim: use ## for automake comments The ## marker tells automake to not include the comment in its generated output, so use that in most places where the comment only makes sense in the inputs.
2021-12-09 14:40:28 +08:00
## FIXME: Use of `mono' is wip.
sim: hoist cgen mloop rules up to common builds These rules don't depend on the target compiler settings, so hoist the build logic up to the common builds for better parallelization. We have to extend the genmloop.sh logic a bit to allow outputting to a subdir since it always assumed cwd was the right place. We leave the cgen maintainer rules in the subdirs for now as they aren't normally run, and they rely on cgen logic that has not yet been generalized.
2021-10-31 15:29:36 +08:00
%D%/mloop.c %D%/eng.h: %D%/stamp-mloop ; @true
sim: cgen: unify the genmloop logic a bit 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.
2023-12-20 08:54:13 +08:00
%D%/stamp-mloop: %D%/mloop.in $(srccom)/genmloop.sh
$(AM_V_GEN)$(CGEN_GEN_MLOOP) \
sim: hoist cgen mloop rules up to common builds These rules don't depend on the target compiler settings, so hoist the build logic up to the common builds for better parallelization. We have to extend the genmloop.sh logic a bit to allow outputting to a subdir since it always assumed cwd was the right place. We leave the cgen maintainer rules in the subdirs for now as they aren't normally run, and they rely on cgen logic that has not yet been generalized.
2021-10-31 15:29:36 +08:00
-mono -scache -parallel-generic-write -parallel-only \
sim: cgen: unify the genmloop logic a bit 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.
2023-12-20 08:54:13 +08:00
-cpu frvbf
sim: hoist cgen mloop rules up to common builds These rules don't depend on the target compiler settings, so hoist the build logic up to the common builds for better parallelization. We have to extend the genmloop.sh logic a bit to allow outputting to a subdir since it always assumed cwd was the right place. We leave the cgen maintainer rules in the subdirs for now as they aren't normally run, and they rely on cgen logic that has not yet been generalized.
2021-10-31 15:29:36 +08:00
$(AM_V_at)$(SHELL) $(srcroot)/move-if-change %D%/eng.hin %D%/eng.h
$(AM_V_at)$(SHELL) $(srcroot)/move-if-change %D%/mloop.cin %D%/mloop.c
$(AM_V_at)touch $@
sim: build: clean more generated outputs
2024-01-09 09:27:23 +08:00
CLEANFILES += %D%/eng.h
sim: hoist cgen mloop rules up to common builds These rules don't depend on the target compiler settings, so hoist the build logic up to the common builds for better parallelization. We have to extend the genmloop.sh logic a bit to allow outputting to a subdir since it always assumed cwd was the right place. We leave the cgen maintainer rules in the subdirs for now as they aren't normally run, and they rely on cgen logic that has not yet been generalized.
2021-10-31 15:29:36 +08:00
MOSTLYCLEANFILES += $(%C%_BUILD_OUTPUTS)
sim: frv: hoist cgen rules to top-level
2023-01-02 10:18:50 +08:00
## Target that triggers all cgen targets that works when --disable-cgen-maint.
%D%/cgen: %D%/cgen-arch %D%/cgen-cpu-decode
%D%/cgen-arch:
$(AM_V_GEN)mach=all FLAGS="with-scache"; $(CGEN_GEN_ARCH)
sim --enable-cgen-maint 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.
2023-08-10 09:42:39 +08:00
$(srcdir)/%D%/arch.h $(srcdir)/%D%/arch.c $(srcdir)/%D%/cpuall.h: @CGEN_MAINT@ %D%/cgen-arch
sim: frv: hoist cgen rules to top-level
2023-01-02 10:18:50 +08:00
%D%/cgen-cpu-decode:
$(AM_V_GEN)cpu=frvbf mach=frv,fr550,fr500,fr450,fr400,tomcat,simple FLAGS="with-scache with-profile=fn with-generic-write with-parallel-only" EXTRAFILES="$(CGEN_CPU_SEM)"; $(CGEN_GEN_CPU_DECODE)
sim --enable-cgen-maint 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.
2023-08-10 09:42:39 +08:00
$(srcdir)/%D%/cpu.h $(srcdir)/%D%/sem.c $(srcdir)/%D%/model.c $(srcdir)/%D%/decode.c $(srcdir)/%D%/decode.h: @CGEN_MAINT@ %D%/cgen-cpu-decode
Reference in New Issue Copy Permalink