[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1266267898.16346.135.camel@pasglop>
Date: Tue, 16 Feb 2010 08:04:58 +1100
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Pavel Machek <pavel@....cz>
Cc: paulus@...ba.org, linuxppc-dev@...abs.org,
kernel list <linux-kernel@...r.kernel.org>,
Segher Boessenkool <segher@...nel.crashing.org>,
bergner@...t.ibm.com
Subject: Re: register long sp asm("r1") incorrect
On Mon, 2010-02-15 at 21:28 +0100, Pavel Machek wrote:
> On Tue 2010-02-16 06:59:52, Benjamin Herrenschmidt wrote:
> > On Mon, 2010-02-15 at 08:34 +0100, Pavel Machek wrote:
> > > > On Tue, 2010-02-09 at 16:24 +0100, Pavel Machek wrote:
> > > > > ...according to gcc docs, sp should be global, or placement in
> > > > > register is not guaranteed (except at asm boundaries, but there
> > > are
> > > > > none).
> > > >
> > > > Sorry I'm not sure I grok what you mean.
> > >
> > > Well, according to gcc doscs and my experience, local "register int
> > > __asm()" variables only work by accident (or not at all).
> >
> > Hrm... we definitely rely on that for our thread_info() access, and so
> > far it has worked well for us, but I'll poke our gcc folks just in case.
>
> Thanks, and let me know about any results.
All the gcc folks I talked to say something along the lines that there
is no way in hell it doesn't work :-)
It's true that most other use of it we have are global scope (local_paca
in r13, glibc use of r2/r13, etc...) afaik, but since r1 itself is the
stack pointer always, I think they pretty much guarantee it works.
I'm CCing a couple of experts just to be sure.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists