On Thu, Feb 24, 2022 at 6:05 AM Nicholas Piggin npiggin@gmail.com wrote:
Excerpts from Nicholas Piggin's message of February 24, 2022 12:54 pm:
Not sure on the outlook for GCC fix. Either way unfortunately we have toolchains in the wild now that will explode, so we might have to take your patches for the time being.
Perhaps not... Here's a hack that seems to work around the problem.
The issue of removing -many from the kernel and replacing it with appropriate architecture versions is an orthogonal one (that we should do). Either way this hack should be able to allow us to do that as well, on these problem toolchains.
But for now it just uses -many as the trivial regression fix to get back to previous behaviour.
I don't think the previous behavior is what you want to be honest.
We had the same thing on Arm a few years ago when binutils started enforcing this more strictly, and it does catch actual bugs. I think annotating individual inline asm statements is the best choice here, as that documents what the intention is.
There is one more bug in this series that I looked at with Anders, but he did not send a patch for that so far:
static void dummy_perf(struct pt_regs *regs) { #if defined(CONFIG_FSL_EMB_PERFMON) mtpmr(PMRN_PMGC0, mfpmr(PMRN_PMGC0) & ~PMGC0_PMIE); #elif defined(CONFIG_PPC64) || defined(CONFIG_PPC_BOOK3S_32) if (cur_cpu_spec->pmc_type == PPC_PMC_IBM) mtspr(SPRN_MMCR0, mfspr(SPRN_MMCR0) & ~(MMCR0_PMXE|MMCR0_PMAO)); #else mtspr(SPRN_MMCR0, mfspr(SPRN_MMCR0) & ~MMCR0_PMXE); #endif }
Here, the assembler correctly flags the mtpmr/mfpmr as an invalid instruction for a combined 6xx kernel: As far as I can tell, these are only available on e300 but not the others, and instead of the compile-time check for CONFIG_FSL_EMB_PERFMON, there needs to be some runtime check to use the first method on 83xx but the #elif one on the other 6xx machines.
Arnd