[Top] [All Lists]

Re: [PATCH] Improve atomic.h implementation robustness

To: "Maciej W. Rozycki" <>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
From: Thiemo Seufer <>
Date: Thu, 2 Dec 2004 00:03:32 +0100
Cc: Dominic Sweetman <>,,, Nigel Stephens <>, David Ung <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <>
User-agent: Mutt/1.5.6i
Maciej W. Rozycki wrote:
> On Wed, 1 Dec 2004, Thiemo Seufer wrote:
> > The compiler was improved with PIC code in mind. The kernel is
> > non-PIC, and can't allow explicit relocs by the compiler because
> > of the weird code model used for 64bit kernels. This led to some
> > degradation and even subtle failures for inline assembly code which
> > relies on assumptions about earlier compiler's behaviour.
>  What do you mean by "the weird code model" and what failures have you 
> observed?  I think the bits are worth being done correctly, so I'd like 
> to know what problems to address.

I had guessed you already know what i mean. :-)

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). This optimization relies on an assembler macro
expansion mode which was hacked in gas for exactly this purpose. Gcc
currently doesn't have something similiar, and would try to do a regular
64bit load with explicit relocs.

I discussed this with Richard Sandiford a while ago, and the conclusion
was to implement an explicit --msym32 option for both gcc and gas to
improve register scheduling and get rid of the gas hack. So far, nobody
came around to actually do the work for it.

For the "subtle failures" part, we had some gas failures to handle dla
because of the changed arguments. For userland (PIC) code, I've also
seen additional load/store insn creeping in ll/sc loops. I believe
there's a large amount of inline assembly code (not necessarily in the
kernel) which relies on similiar assumptions.


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