aboutsummaryrefslogtreecommitdiff
path: root/sim
AgeCommit message (Collapse)AuthorFilesLines
2023-01-10sim: d10v: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: cris: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: cr16: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: bfin: move arch-specific file compilation to top-levelMike Frysinger3-8/+3
The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-10sim: bpf: move arch-specific file compilation to top-levelMike Frysinger3-29/+15
We can drop the arch-specific rules from the subdir as they're no longer used.
2023-01-10sim: avr: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: arm: move arch-specific file compilation to top-levelMike Frysinger3-9/+3
The arch-specific flags are only used by the arch-specific modules, not the common/ files, so we can delete them too.
2023-01-10sim: aarch64: move arch-specific file compilation to top-levelMike Frysinger2-6/+0
2023-01-10sim: build: add basic framework for compiling arch objects in top-levelMike Frysinger4-10/+31
The code so far has been assuming that we only compile common/ objects. Now that we're ready to compile arch-specific objects, refactor some of the flags & checks a bit to support both.
2023-01-10sim: modules.c: move generation to top-levelMike Frysinger3-32/+49
Now that all arches create libsim.a from the top-level, we have full access to their inputs, and can move the actual generation from the subdir up to the top-level. This avoids recursive makes and will help simplify state passing between the two.
2023-01-10sim: build: drop common/nrun.o subdir hackMike Frysinger2-6/+0
Now that all the subdirs handle their own builds, we can drop this common rule as it's unused, and we don't want to use it anymore.
2023-01-10sim: build: drop support for creating libsim.a in subdirsMike Frysinger36-130/+3
Now that all ports have moved to creating libsim.a in the top-level, drop all the support code to create it in a subdir.
2023-01-10sim: v850: move libsim.a creation to top-levelMike Frysinger3-20/+88
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.
2023-01-10sim: sh: move libsim.a creation to top-levelMike Frysinger3-27/+74
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.
2023-01-10sim: rx: move libsim.a creation to top-levelMike Frysinger3-42/+87
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.
2023-01-10sim: rl78: move libsim.a creation to top-levelMike Frysinger3-41/+78
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.
2023-01-10sim: riscv: move libsim.a creation to top-levelMike Frysinger3-31/+83
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.
2023-01-10sim: pru: move libsim.a creation to top-levelMike Frysinger3-31/+80
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.
2023-01-10sim: or1k: move libsim.a creation to top-levelMike Frysinger3-52/+122
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.
2023-01-10sim: msp430: move libsim.a creation to top-levelMike Frysinger3-37/+86
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.
2023-01-10sim: moxie: move libsim.a creation to top-levelMike Frysinger3-37/+87
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.
2023-01-10sim: mn10300: move libsim.a creation to top-levelMike Frysinger3-46/+118
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.
2023-01-10sim: mips: move libsim.a creation to top-levelMike Frysinger5-153/+251
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. The mips code is a little more tricky than others because, for multi-run targets, it generates the list of sources & objects on the fly in the configure script.
2023-01-10sim: microblaze: move libsim.a creation to top-levelMike Frysinger3-57/+106
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.
2023-01-10sim: mcore: move libsim.a creation to top-levelMike Frysinger3-57/+105
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.
2023-01-10sim: m68hc11: move libsim.a creation to top-levelMike Frysinger3-67/+132
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.
2023-01-10sim: m32r: move libsim.a creation to top-levelMike Frysinger3-77/+186
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.
2023-01-10sim: m32c: move libsim.a creation to top-levelMike Frysinger3-90/+136
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.
2023-01-10sim: lm32: move libsim.a creation to top-levelMike Frysinger3-82/+167
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.
2023-01-10sim: iq2000: move libsim.a creation to top-levelMike Frysinger3-87/+165
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.
2023-01-10sim: h8300: move libsim.a creation to top-levelMike Frysinger3-83/+132
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.
2023-01-10sim: ft32: move libsim.a creation to top-levelMike Frysinger3-86/+133
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.
2023-01-10sim: frv: move libsim.a creation to top-levelMike Frysinger3-96/+209
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.
2023-01-10sim: example-synacor: move libsim.a creation to top-levelMike Frysinger3-91/+143
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.
2023-01-10sim: erc32: move libsim.a creation to top-levelMike Frysinger3-100/+148
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.
2023-01-10sim: d10v: move libsim.a creation to top-levelMike Frysinger3-104/+157
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.
2023-01-10sim: cris: move libsim.a creation to top-levelMike Frysinger3-115/+205
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.
2023-01-10sim: cr16: move libsim.a creation to top-levelMike Frysinger3-116/+167
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.
2023-01-10sim: bpf: move libsim.a creation to top-levelMike Frysinger3-126/+207
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.
2023-01-10sim: bfin: move libsim.a creation to top-levelMike Frysinger3-125/+181
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.
2023-01-10sim: avr: move libsim.a creation to top-levelMike Frysinger3-121/+168
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.
2023-01-10sim: arm: move libsim.a creation to top-levelMike Frysinger3-125/+181
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.
2023-01-10sim: aarch64: move libsim.a creation to top-levelMike Frysinger4-129/+184
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.
2023-01-10sim: build: drop support for subdir extra depsMike Frysinger2-17/+0
Nothing uses this hook anymore, so punt it. It was largely used to track generated files (which we do in the top-level now) and extra header files (which we use automake depgen for now).
2023-01-10sim: modules: trigger generation from top-levelMike Frysinger18-10/+67
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.
2023-01-04sim: mips: add multi source to built sourcesMike Frysinger2-1/+6
The multirun generation mode is a bit of a mess as generated run files depend on generate igen files, all with unknown names ahead of time. In the multirun mode, be lazy and declare all of these generated source files as built sources so they'll be created early on.
2023-01-05sim: Move getopt checking inside SIM_AC_PLATFORMTsukasa OI3-42/+46
This commit moves getopt declaration checker originally in sim/ configure.ac; added in commit 340aa4f6872c ("sim: Check known getopt definition existence") to sim/m4/sim_ac_platform.m4 (inside the SIM_AC_PLATFORM macro). It also regenerates configuration files using the maintainer mode.
2023-01-04sim: bpf: fix testsuite due to linker warnings [PR sim/29954]Guillermo E. Martinez1-4/+1
On a bpf-*-* testsuite fails: ./ld/ld-new: warning: test has a LOAD segment with RWX permissions Adjusting `--memory-size=10Mb' to the simulator bpf testsuite passes. Tested on bpf-*-*: Bug: https://sourceware.org/PR29954 sim/testsuite: * bpf/allinsn.exp (SIMFLAGS_FOR_TARGET): Adjust sim flags.
2023-01-04sim: Regenerate using the maintainer modeTsukasa OI1-1/+1
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 319e41e83a40 ("sim: ppc: inline the sim-packages option").
2023-01-02sim: sh: move some generated source files to built sourcesMike Frysinger2-13/+20
This should have been part of the previous commit 80636a54bcfa2bca3dc8f ("sim: build: move generated headers to built sources"), but they were missed because they're .c files effectively treated as .h files.
generated by cgit v1.1 at 2025-01-17 02:11:09 +0000