Fredrik, > > > How can one reasonably prevent the bug when compiling a whole Linux > > > distribution with thousands of packages if GAS merely warns and proceeds > > > in many cases? > > > > I think the tools must not set a policy. By using `.set noreorder' the > > user told the toolchain he knows better and asked to keep its hands away. > > > > As I say you can use `-Werror' for code auditing. And in most cases > > manually scheduled delay slots in handcoded assembly are a sign of a > > problem with the piece of code affected, regardless of the R5900 erratum. > > Well, it seems practical to use unofficial tools and a patched GAS to fix > this assembly bug, then. It's a grave problem for the R5900 and it needs to > be reliably detected.
Why? What is wrong with using `-Werror'? Or you could use `-Wa,-fatal-warnings' to limit making warnings fatal to the assembly stage only if you are concerned about bad high-level language code quality interfering with your goal. > > See `nops_for_insn'. However again, as I noted, `.set noreorder' tells > > GAS not to analyse the dependencies for code within. There is no need to > > schedule this delay slot manually, and if this is generated code, then the > > producer (GCC) should have taken care of the hazards, be it architectural > > or errata. If this is manually written code, then the author asked for > > trouble. > > I'm using the principle above to unobtrusively adjust problematic kernel > code, via a short_loop_war macro. Here is one patched instance: > > --- a/arch/mips/boot/compressed/head.S > +++ b/arch/mips/boot/compressed/head.S > @@ -13,6 +13,7 @@ > */ > > #include <asm/asm.h> > +#include <asm/asmmacro.h> > #include <asm/regdef.h> > > .set noreorder > @@ -29,6 +30,7 @@ start: > PTR_LA a0, _edata > PTR_LA a2, _end > 1: sw zero, 0(a0) > + short_loop_war(1b) > bne a2, a0, 1b > addiu a0, a0, 4 > > @@ -48,6 +50,7 @@ start: > jr k0 > nop > 3: > + short_loop_war(3b) > b 3b > nop Is it needed here given that the delay slot instruction is a NOP anyway? Also this source does not need `.set noreorder', except for the loop around `1:' where a data dependency is present with the delay slot instruction. And I am surprised that it even assembles as it uses `.cprestore' without the required offset argument (not that this pseudo-op makes any sense here). And it's weird overall, e.g. it loads $ra explicitly rather than using JALR (or JAL even). But these are unrelated problems. > > Well, BogoMIPS is just an arbitrary number. > > So presumably the noreorder BogoMIPS variant can be replaced with a > single reorder variant that works with all MIPS implementations? Sure, BogoMIPS just records how quickly the delay loop runs, and therefore how many iterations are required for a given amount of time to spend twiddling thumbs. Maciej
