[Top] [All Lists]

Re: .set mips2 breaks 64bit kernel (Re: CVS linux

To: Kumba <>
Subject: Re: .set mips2 breaks 64bit kernel (Re: CVS linux)
From: "Maciej W. Rozycki" <>
Date: Wed, 22 Jun 2005 14:30:41 +0100 (BST)
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
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.


<Prev in Thread] Current Thread [Next in Thread>