Hi, On Tue, Jul 07, 2015 at 01:44:15PM -0500, Segher Boessenkool wrote: > On Tue, Jul 07, 2015 at 07:53:49PM +0200, Martin Jambor wrote: > > I've been asked to look into the item one of > > http://permalink.gmane.org/gmane.linux.kernel/1990397 and found out > > that at least shrink-wrapping happily moves prologue past an asm > > statement which can be bad if the asm statement contains a call > > instruction. > > > > Am I right concluding that this is a bug? Looking into the manual and > > at requires_stack_frame_p() in shrink-wrap.c, I do not see any obvious > > way of marking the asm statement as requiring the stack frame (but I > > will not mind being proven wrong). Do we want to create one, such as > > only disallowing moving prologue past volatile asm statements? Any > > other ideas? > > For architectures like PowerPC where all calls clobber some register, > you can write e.g. > > asm("bl func" : : : "lr"); > > and all is well (better than saving/restoring LR manually, too). > > > For other archs, e.g. x86-64, you can do > > register void *sp asm("%sp"); > asm volatile("call func" : "+r"(sp)); >
Thanks, this is very clever and apparently what is going to be used: https://lkml.org/lkml/2015/7/7/1071 > and the result seems to be optimal as well. > > > Some special clobber, maybe "stack" (like "memory", which won't work) > could be nicer? What should the *exact* semantics of that be? > 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. I'm CCing Josh who has been bitten by this, perhaps he can share some insight. 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. Using a register variable seems like a workaround, so having a "stack" input operand is probably worth some further thought. Martin
