On Wed, 22 Jun 2005, Kumba wrote: > I've tested to see it break IP30, and Thiemo reported IP27 was also not > booting (no text display after kernel entry). Reversing this patch seems to > allow both systems to boot. Is it possible it breaks ELF64-only builds? I > haven't tested it on IP28 yet, so I can't confirm this (it's also ELF64). Well, could I please ask people to be more specific when writing such reports? Unfortunately "break" can mean anything and my crystal ball is currently away for a service. At least you've mentioned problems at a bootstrap, so I infer it's not a build-time failure. That said, I'm only using ELF64 for my 64-bit builds, so that shouldn't be the cause. But I think there is one possiblity of a problem -- obsolete versions of GCC may rely on gas expanding "ll" and "sc" as macros, i.e. substitute a name of a symbol rather than a valid machine-level address expression (e.g. "0($reg)" or "%lo(sym)($reg)") for memory constraints. Well, by using "m" right now we sort of permit it to. But shouldn't gas actually complain if the ISA or CPU selection forbids it doing the right address calculation for the ABI in use? I think it should, so I consider it a bug in gas. Of course, blaming gas doesn't magically make our code right, but the deficiency makes noticing such problems tougher. As we still strive to support old versions of GCC, I guess a reasonable solution is taking an approach similar to that I already have in include/asm-mips/bitops.h, i.e. defining __SET_MIPS appropriately and using it instead of hardcoded ".set mips2". I'll prepare a fix shortly. Maciej
