Use probe-stack=inline-asm in LLVM 11+ #77885
Conversation
|
Thanks! This may have perf implications, so I'm excluding it from rollups. @bors r+ rollup=never |
|
|
Use probe-stack=inline-asm in LLVM 11+ Fixes (?) rust-lang#74405, related to rust-lang#43241 r? `@cuviper`
|
|
|
The specific failures start here. I'm not sure why this change would cause new stack overflows, but it needs investigation.
|
|
Looks like a comparison is inverted. This is a code snippet from add ebx, 15
and ebx, -16
mov eax, esp
sub eax, ebx
mov dword ptr [ebp - 368], edx
mov dword ptr [ebp - 372], esi
mov dword ptr [ebp - 376], edi
mov dword ptr [ebp - 380], eax
.LBB87_43:
mov eax, dword ptr [ebp - 380]
cmp eax, esp
jl .LBB87_45
mov dword ptr [esp], 0
sub esp, 4096
jmp .LBB87_43
.LBB87_45:
mov eax, dword ptr [ebp - 380]
mov esp, eaxDue to: cmp eax, esp
jl .LBB87_45...if The same thing shows up in Clang 11 with int size;
void foo(void*);
int main() {
foo(alloca(size));
}I suppose nobody noticed this in C because it's rare to call Assuming I haven't misinterpreted something, can you report this to LLVM? I don't have an account yet. |
|
@bors r- The PR failed but bors forgot about that during synchronize. |
|
Hmm, I thought we fixed that |
|
Yeah, the changes to |
|
@erikdesjardins / @cuviper https://reviews.llvm.org/D90216 should do the trick. Thanks for spotting this! |
|
Ah, so there are two parts to this...
This actually was already reported in bug 47657 and fixed in D88548.
This problem remains, but I just confirmed locally that it is fixed by D90216. I stepped through the assembly in gdb just to be sure. I think both fixes would be good to have in LLVM 11.0.1. For Rust's part, we can backport the fixes to our bundled LLVM fork, but we should be careful about how this is enabled for external LLVM. I don't think we usually check the patch version for functionality, but maybe this one justifies it -- assuming 11.0.1 does get fixed. |
- Perform the probing in the correct direction. Related to rust-lang/rust#77885 (comment) - The first touch on a dynamic alloca cannot use a mov because it clobbers existing space. Use a xor 0 instead Differential Revision: https://reviews.llvm.org/D90216
- Perform the probing in the correct direction. Related to rust-lang/rust#77885 (comment) - The first touch on a dynamic alloca cannot use a mov because it clobbers existing space. Use a xor 0 instead Differential Revision: https://reviews.llvm.org/D90216
|
Triage: So it seems this is blocked on a llvm bug. |
- Perform the probing in the correct direction. Related to rust-lang/rust#77885 (comment) - The first touch on a dynamic alloca cannot use a mov because it clobbers existing space. Use a xor 0 instead Differential Revision: https://reviews.llvm.org/D90216 (cherry picked from commit 0f60bcc)
- Perform the probing in the correct direction. Related to rust-lang/rust#77885 (comment) - The first touch on a dynamic alloca cannot use a mov because it clobbers existing space. Use a xor 0 instead Differential Revision: https://reviews.llvm.org/D90216 (cherry picked from commit 0f60bcc)
- Perform the probing in the correct direction. Related to rust-lang/rust#77885 (comment) - The first touch on a dynamic alloca cannot use a mov because it clobbers existing space. Use a xor 0 instead Differential Revision: https://reviews.llvm.org/D90216 (cherry picked from commit 0f60bcc)
|
Rebased. |
|
@bors r+ |
|
|
|
|
…iper Target stack-probe support configurable finely This adds capability to configure the target's stack probe support in a more precise manner than just on/off. In particular now we allow choosing between always inline-asm, always call or either one of those depending on the LLVM version. Note that this removes the ability to turn off the generation of the stack-probe attribute. This is valid to replace it with inline-asm for all targets because `probe-stack="inline-asm"` will not generate any machine code on targets that do not currently support stack probes. This makes support for stack probes on targets that don't have any right now automatic with LLVM upgrades in the future. (This is valid to do based on the fact that clang unconditionally sets this attribute when `-fstack-clash-protection` is used, AFAICT) cc rust-lang#77885 r? `@cuviper`
…iper Target stack-probe support configurable finely This adds capability to configure the target's stack probe support in a more precise manner than just on/off. In particular now we allow choosing between always inline-asm, always call or either one of those depending on the LLVM version. Note that this removes the ability to turn off the generation of the stack-probe attribute. This is valid to replace it with inline-asm for all targets because `probe-stack="inline-asm"` will not generate any machine code on targets that do not currently support stack probes. This makes support for stack probes on targets that don't have any right now automatic with LLVM upgrades in the future. (This is valid to do based on the fact that clang unconditionally sets this attribute when `-fstack-clash-protection` is used, AFAICT) cc rust-lang#77885 r? `@cuviper`
To buy time on issue 83139, revert effect of PR 77885: We will not conditionally enable probe-stack=inline-asm on LLVM 11+ anymore on any of our targets that opted into doing so on PR rust-lang#77885 (and were subsequently configured to do so in a fine grained manner on PR rust-lang#80838). After we resolve 83139 (potentially by backporting a fix to LLVM, or potentially by deciding that one cannot rely on the quality of our DWARF output in the manner described in issue 83139), we can change this back.
To buy time on issue 83139, revert effect of PR 77885: We will not conditionally enable probe-stack=inline-asm on LLVM 11+ anymore on any of our targets that opted into doing so on PR rust-lang#77885 (and were subsequently configured to do so in a fine grained manner on PR rust-lang#80838). After we resolve 83139 (potentially by backporting a fix to LLVM, or potentially by deciding that one cannot rely on the quality of our DWARF output in the manner described in issue 83139), we can change this back. (Update: fixed formatting issue.)
| @@ -13,11 +13,12 @@ | |||
| // ignore-emscripten | |||
| // ignore-windows | |||
| // compile-flags: -C no-prepopulate-passes | |||
| // min-llvm-version: 11.0.1 | |||
pnkfelix
Mar 23, 2021
Member
by the way, doesn't adding this mean that we are effectively no longer unit-testing our old stack-probe strategy, since we will just skip this test if the LLVM version is not sufficiently new?
Maybe we should have two files, one for LLVM < 11.0.1 and one for LLVM >= 11.0.1?
by the way, doesn't adding this mean that we are effectively no longer unit-testing our old stack-probe strategy, since we will just skip this test if the LLVM version is not sufficiently new?
Maybe we should have two files, one for LLVM < 11.0.1 and one for LLVM >= 11.0.1?
nagisa
Mar 23, 2021
Contributor
We don't generally test very meticulously the setups that use LLVM versions outside of what is in the Rust repository. This is reflected in e.g. tests for all our (oft backported) soundness fixes only being applicable to the newest LLVM versions and our fork.
So far it has been the unwritten policy that it is up to the users who build with alternative LLVM versions to ensure that their builds do what they expect. (This is also another of those things that I should eventually look into codifying in some document outlining our LLVM support strategy)
We don't generally test very meticulously the setups that use LLVM versions outside of what is in the Rust repository. This is reflected in e.g. tests for all our (oft backported) soundness fixes only being applicable to the newest LLVM versions and our fork.
So far it has been the unwritten policy that it is up to the users who build with alternative LLVM versions to ensure that their builds do what they expect. (This is also another of those things that I should eventually look into codifying in some document outlining our LLVM support strategy)
…7885-for-issue-83139, r=nagisa [stable] probe-stack=call everywhere again, for now. To buy time on issue 83139, revert effect of PR 77885: We will not conditionally enable probe-stack=inline-asm on LLVM 11+ anymore on any of our targets that opted into doing so on PR rust-lang#77885 (and were subsequently configured to do so in a fine grained manner on PR rust-lang#80838). After we resolve 83139 (potentially by backporting a fix to LLVM, or potentially by deciding that one cannot rely on the quality of our DWARF output in the manner described in issue 83139), we can change this back. cc rust-lang#83139
- Perform the probing in the correct direction. Related to rust-lang/rust#77885 (comment) - The first touch on a dynamic alloca cannot use a mov because it clobbers existing space. Use a xor 0 instead Differential Revision: https://reviews.llvm.org/D90216
Fixes (?) #74405, related to #43241
r? @cuviper