__builtin_setjmp miscompiles on x86_64-pc-windows-msvc

[duk-37]

Clang relies on llvm.frameaddress(0) returning RBP, which isn't the case on X64 Windows (see X86IselLowering::LowerFRAMEADDR).

NOTE: I'm not sure whether this is a Clang implementation issue or if one could interpret it as LLVM making a bad assumption during codegen. I marked it as the former but this is up for debate and I'm starting to lean towards the latter.

Repro:

void *buf[5];

void foo() {
    __builtin_longjmp(buf, 1);
}

int main() {
   if (!__builtin_setjmp(buf)) {
        foo();
   }
}

Relevant assembly:

lea rax, [rbp - 128]
mov qword ptr [rip + buf], rax

Godbolt link

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Author: duk (duk-37)

Clang relies on `llvm.frameaddress(0)` returning RBP, which isn't the case on X64 Windows (see `X86IselLowering::LowerFRAMEADDR`).

Repro:

void *buf[5];

void foo() {
    __builtin_longjmp(buf, 1);
}

int main() {
   if (!__builtin_setjmp(buf)) {
        foo();
   }
}

[folkertdev]

we're running into this too (on x86_64-pc-windows-gnu, but I think the problem is the same).

Is it your impression that the output of frameaddress(i32 0) is incorrect?

I made this LLVM IR reproduction, suggesting that it is really an LLVM and not a clang problem:

@buf = internal global [5 x i8*] zeroinitializer

declare i8* @llvm.frameaddress(i32) nounwind readnone

declare i8* @llvm.stacksave() nounwind

declare i32 @llvm.eh.sjlj.setjmp(i8*) nounwind

declare void @llvm.eh.sjlj.longjmp(i8*) nounwind

define i32 @main(ptr %output) {
  %value = alloca [4 x i64], align 8
  call void @sj0(ptr %value)
  ret i32 0
}

define void @sj0(ptr %output) nounwind {
entry:
  %fp = tail call i8* @llvm.frameaddress(i32 0)
  store i8* %fp, i8** getelementptr inbounds ([5 x i8*], [5 x i8*]* @buf, i64 0, i64 0), align 16
  %sp = tail call i8* @llvm.stacksave()
  store i8* %sp, i8** getelementptr inbounds ([5 x i8*], [5 x i8*]* @buf, i64 0, i64 2), align 16
  %r = tail call i32 @llvm.eh.sjlj.setjmp(i8* bitcast ([5 x i8*]* @buf to i8*))
  %cmp = icmp eq i32 %r, 0
  br i1 %cmp, label %initial_call, label %after_longjmp

initial_call:
  call void @lj0()
  unreachable

after_longjmp:
  %set_output = insertvalue [ 4 x i64 ] zeroinitializer, i64 84, 0
  store [4 x i64] %set_output, ptr %output, align 8
  ret void
}  
 
define void @lj0() nounwind {
  tail call void @llvm.eh.sjlj.longjmp(i8* bitcast ([5 x i8*]* @buf to i8*))
  unreachable
}

Is it your impression that the output of frameaddress(i32 0) is incorrect? in other words should

  lea rax, [rbp - 128]
  mov qword ptr [rip + buf], rax

just be

  mov rax, rbp
  mov qword ptr [rip + buf], rax

btw just for extra context, this rbp - 128 seems to be a result of storing the simd registers

  140001000:   	push	rbp
  140001001:   	push	r15
  140001003:   	push	r14
  140001005:   	push	r13
  140001007:   	push	r12
  140001009:   	push	rsi
  14000100a:   	push	rdi
  14000100b:   	push	rbx
  14000100c:   	sub	rsp, 0xd8
  140001013:  	lea	rbp, [rsp + 0x80]                    <---- rbp = rsp + 0x80
  14000101b:  	movaps	xmmword ptr [rbp + 0x40], xmm15
  140001020:  	movaps	xmmword ptr [rbp + 0x30], xmm14
  140001025:  	movaps	xmmword ptr [rbp + 0x20], xmm13
  14000102a:  	movaps	xmmword ptr [rbp + 0x10], xmm12
  14000102f:  	movaps	xmmword ptr [rbp], xmm11
  140001034:  	movaps	xmmword ptr [rbp - 0x10], xmm10
  140001039:  	movaps	xmmword ptr [rbp - 0x20], xmm9
  14000103e:  	movaps	xmmword ptr [rbp - 0x30], xmm8
  140001043:  	movaps	xmmword ptr [rbp - 0x40], xmm7
  140001047:  	movaps	xmmword ptr [rbp - 0x50], xmm6
  14000104b:  	mov	qword ptr [rbp - 0x58], rcx
  14000104f:  	lea	rax, [rbp - 0x80]                    <---- rax = rbp - 0x80 (which is just rsp really)
  140001053:  	mov	qword ptr [rip + 0xac2b6], rax # 0x1400ad310

[duk-37]

Is it your impression that the output of frameaddress(i32 0) is incorrect?

The problem is that frameaddress might not be the right tool for the job here, so to speak. This is because FRAMEADDR on the x86 backend has a special case added on Windows X64, which is needed because of differences in stack frame layout you can see here -- namely, unlike on Linux, rbp on Windows does not point to the top of the function frame when callee-saved registers are added to the mix.

That being said, the right fix here may be to remove the exceptional case in LowerFRAMEADDR and forcing people to use a different intrinsic instead... at the expense of breaking existing code. You could, however, also make the argument that FRAMEADDR is doing exactly what it's designed to do: get the top of the function frame. That just happens to not be rbp in this case.

I made this LLVM IR reproduction, suggesting that it is really an LLVM and not a clang problem:

Right, the problem itself is not a miscompile in clang per-se, it's that using frameaddress may not obey the desired semantics.