sim: modules.c: fix generation after recent refactors
authorMike Frysinger <vapier@gentoo.org>
Mon, 16 Jan 2023 01:48:28 +0000 (20:48 -0500)
committerMike Frysinger <vapier@gentoo.org>
Mon, 16 Jan 2023 01:55:48 +0000 (20:55 -0500)
commit109a0a7e902f23e7167f89abbc0d8fa0ccca6594
tree69140c62ef540d70211485d814b435ab235e3132
parent8cf531c3dbf593dd3159950dc3fa1bba2c00ac5e
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.
32 files changed:
sim/Makefile.in
sim/aarch64/local.mk
sim/arm/local.mk
sim/avr/local.mk
sim/bfin/local.mk
sim/bpf/local.mk
sim/cr16/local.mk
sim/cris/local.mk
sim/d10v/local.mk
sim/erc32/local.mk
sim/example-synacor/local.mk
sim/frv/local.mk
sim/ft32/local.mk
sim/h8300/local.mk
sim/iq2000/local.mk
sim/lm32/local.mk
sim/m32c/local.mk
sim/m32r/local.mk
sim/m68hc11/local.mk
sim/mcore/local.mk
sim/microblaze/local.mk
sim/mips/local.mk
sim/mn10300/local.mk
sim/moxie/local.mk
sim/msp430/local.mk
sim/or1k/local.mk
sim/pru/local.mk
sim/riscv/local.mk
sim/rl78/local.mk
sim/rx/local.mk
sim/sh/local.mk
sim/v850/local.mk