[Top] [All Lists]

Re: [PATCH] Improve atomic.h implementation robustness

To: Thiemo Seufer <>
Subject: Re: [PATCH] Improve atomic.h implementation robustness
From: "Maciej W. Rozycki" <>
Date: Thu, 2 Dec 2004 00:17:56 +0000 (GMT)
Cc: Dominic Sweetman <>,,, Nigel Stephens <>, David Ung <>
In-reply-to: <>
Original-recipient: rfc822;
References: <> <> <> <> <>
On Thu, 2 Dec 2004, Thiemo Seufer wrote:

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

 Ah *that*.  Well, sorry -- I tend to forget about the hack as I've never
used it.  I think a valid solution is either to use CONFIG_BUILD_ELF64
(now that it is there) or to modify tools to implement it correctly...

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

 ... like this, for example.  But if nobody has implemented it yet, then 
perhaps nobody is really interested in 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

 I recall this -- I've thought the more or less agreed consensus was to
forbid or at least strongly discourage "dla" and "la" macros expanded
within inline asms and referring to an address operand to be provided by
GCC based on a constraint.

 Otherwise there is still my patch to gas available as an alternative. ;-)

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

 With explicit relocs you have no problem with any instructions appearing 
inside inline asms unexpectedly.  That is if you use the "R" constraint -- 
the "m" one never guaranteed that.


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