[llvm-dev] Stack pointer updates and hoisting/scheduling vs interrupts

[mats petersson via llvm-dev]

Can't really help here, but it does sound wrong, and something that the
compiler should be able to "deal with" (that "this is a stack adjustment,
and it needs to be done atomically before stack is used"). I've run into
similar bugs in the past, where some [not clang+llvm] compiler doesn't
understand that the stack pointer is not "only used by this function".

--
Mats

On 16 October 2017 at 12:08, Mikael Holmén via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi llvm-dev,
>
> On a number of occations we've run into different versions of problems
> with our out-of-tree target when it comes to scheduling of stack pointer
> updates vs interrupts at unfortunate places.
>
> Example:
>
> If we allocate an object on the stack with alignment we get something like:
>
> mv sp, r0
> sub r0, 2, r0
> and r0, 0xfffe, r0
> mv r0, sp
>
> and then there might follow an instruction storing to the allocated space:
>
> store 42, r0
>
> and further down a load from it
>
> load r0, r1
>
> The problem we've run into is that the store is scheduled before the
> update of sp:
>
> mv sp, r0
> sub r0, 2, r0
> and r0, 0xfffe, r0
> store 42, r0
> mv r0, sp
>
> This works well in most cases, but if we are unfortunate enough to trigger
> an interrupt after the store, but before the sp update, the interrupt code
> might overwrite the stuff that the store just wrote to the stack, so when
> we continue after the interrupt, the last load might read rubbish data.
>
> The store is only depending on r0, but we would like to make sure that the
> actual move to sp is carried out before it too.
>
> I've failed to see how other targets solve this kind of problem, I suppose
> we're not alone in facing this issue?
>
> Regards,
> Mikael
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171016/f51d5efa/attachment.html>