[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