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
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.