linux-mips
[Top] [All Lists]

Re: [PATCH] Improve atomic.h implementation robustness

To: Dominic Sweetman <dom@mips.com>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
From: Thiemo Seufer <ica2_ts@csv.ica.uni-stuttgart.de>
Date: Thu, 2 Dec 2004 09:38:59 +0100
Cc: "Maciej W. Rozycki" <macro@linux-mips.org>, linux-mips@linux-mips.org, ralf@linux-mips.org, Nigel Stephens <nigel@mips.com>, David Ung <davidu@mips.com>
In-reply-to: <16814.52180.502747.597080@doms-laptop.algor.co.uk>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <20041201070014.GG3225@rembrandt.csv.ica.uni-stuttgart.de> <16813.39660.948092.328493@doms-laptop.algor.co.uk> <20041201204536.GI3225@rembrandt.csv.ica.uni-stuttgart.de> <Pine.LNX.4.58L.0412012151210.13579@blysk.ds.pg.gda.pl> <20041201230332.GM3225@rembrandt.csv.ica.uni-stuttgart.de> <16814.52180.502747.597080@doms-laptop.algor.co.uk>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.6i
Dominic Sweetman wrote:
> 
> Thiemo,
> 
> > I had guessed you already know what i mean. :-)
> 
> Generally a bad guess, of course...
> 
> > Current 64bit MIPS kernels run in (C)KSEG0, and exploit sign-extension
> > to optimize symbol loads (2 instead of 6/7 instructions, the same as in
> > 32bit kernels).
> 
> Gross... yet ingenious. I see the problem.  You want to use a
> 32-bit-pointer "la" for the addresses of static variables in the
> kernel build (which works, because the kernel is in the
> 32-bit-pointer-accessible 'kseg0').

Except that the compiler emits a "dla", but the assembler expands
it like "la". :-)

> The assembler macro was a very Linux solution, if you don't mind my
> saying so...  A more native compiler fix would probably be a good
> idea.
> 
> What ABI are you using for the 64-bit kernel build (n64? how do you
> get it to build non-PIC?)

The ABIs are generally only defined for PIC code, the 64bit kernel uses
the n64 non-PIC alike. Building as non-PIC is simple, via
-mabi=64 -fno-PIC -mno-abicalls

> And what constraints are there on
> your choice of gcc version? - it would be easier if 3.4 was OK.

3.2/3.3 are known to work. 3.4 fails for yet unknown reason, I guess
either due to inline assembler changes or more agressive dead code
elimination.


Thiemo

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