[PATCH] D92695: [X86ISelLowering] don't emit frame pointers for eflags intrinsics.

Craig Topper via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Dec 4 15:05:49 PST 2020


craig.topper added a comment.

In D92695#2434996 <https://reviews.llvm.org/D92695#2434996>, @nickdesaulniers wrote:

> In D92695#2434973 <https://reviews.llvm.org/D92695#2434973>, @craig.topper wrote:
>
>> What prevents overwriting something in the red zone?
>
> I don't follow.  How does the kernel prevent overwriting something in the red zone?  I don't know, https://lore.kernel.org/lkml/CALCETrXUaeNUbkQSeMPpPKWDBCEpqX1gLgkv2G9zLeeYMjK8VQ@mail.gmail.com/ was the brief conversation we had on LKML, but I'd have to talk with the x86 maintainers who would know more. Andy Lutomirski seems to imply the kernel may be broken in that regard.
>
> But I also think that is orthogonal to these builtins and frame pointers, or at least I fail to see the relation.

When the red zone is in use, the stack pointer isn't updated to include it. So when the pushfq happens it will push a value into an address that is part of the red zone potentially clobbering something. The setHasCopyImplyingStackAdjust disables the use of the red zone for the function which avoids this issue.

Maybe the linux kernel disables the red zone and this isn't a problem. But I worry about others using these builtins without disabling the red zone.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D92695/new/

https://reviews.llvm.org/D92695



More information about the llvm-commits mailing list