On Wed, Jul 08, 2015 at 05:36:31AM -0500, Segher Boessenkool wrote:
> On Wed, Jul 08, 2015 at 11:23:09AM +0200, Martin Jambor wrote:
> > > For other archs, e.g. x86-64, you can do
> > >
> > > register void *sp asm("%sp");
> > > asm volatile("call func" : "+r"(sp));
>
> <snip>
>
> > Well, I only have had a quick look at where things "go wrong" and have
> > not spent much time thinking about all the things that coud break by
> > moving an asm statement before stack frame setup so I don't know.
>
> What goes wrong is that the "plain" asm (just the call) does not say it
> needs the prologue of this function to be before it. But it needs some
> of its effects: at least it needs the stack pointer changes (by the
> prologue) to be done before it.
>
> Writing the asm with a clobber of the stack pointer causes all stack
> accesses to go via the frame pointer, which causes pretty horrible
> code.
As far as I can tell, most (but not all) kernel stack accesses already
occur via the frame pointer anyway. Is that bad? Can you clarify what
you mean by horrible code?
> Using just an input of the stack pointer, like in
>
> register void *sp asm("%sp");
> asm volatile("call func" : : "r"(sp));
>
> also works, at least in my simple test case; but the version that also
> writes to sp prevents the asm's movement more.
>
> > Nevertheless, given that this was discovered only now, it might not be
> > a common problem but of course it may become one if we improve
> > shrink-wrapping further.
>
> GCC 5 and/or GCC 6 make shrink wrapping more aggressive, quite nice.
>
> > Using a register variable seems like a workaround,
>
> That is only a workaround for the fact that there is no other way to
> say "this input should be in this specific register" (in general;
> some ports have such constraints for some registers).
>
> Having the asm take the stack pointer as input is hackish yes.
>
> > so having a "stack" input operand is probably worth some
> > further thought.
>
> It would be nice if you could just say "this asm has to stay behind
> the prologue", yes. I suggested using a special clobber, not an input,
> but that is just syntax quibbles.
>
> The question is if this usage is common enough to warrant a special
> syntax at all.
In the kernel it only affects a handful of code locations which are
mostly wrapped in macros, so I don't really see the need for a special
syntax. IMO, the existing syntax is fine for the kernel.
Thanks!
--
Josh
