__chkstk function (LLVM36)

[vtjnash]

with LLVM35, it looks like we need to provide llvm with a __chkstk_ms function?

$ make -C test numbers
make: Entering directory '/home/julia/julia64/test'
    JULIA test/numbers
     * numbers
LLVM ERROR: Program used external function '___chkstk_ms' which could not be resolved!
/bin/sh: line 1:  2628 Segmentation fault      /home/julia/julia64/usr/bin/julia.exe --check-bounds=yes -f ./runtests.jl numbers
Makefile:9: recipe for target 'numbers' failed
make: *** [numbers] Error 139
make: Leaving directory '/home/julia/julia64/test'

[tkelman]

Should be in libgcc? I've seen this before, but it was always a sign of misconfigured mingw.

[vtjnash]

I see the symbol in code compiled by libgcc (using the cygwin cross-compile). llvm33 didn't use it, llvm35 now tries to use it, and seems to be unable to find it.

[tkelman]

Was this an msys2 build? In cygwin-to-mingw cross compile I don't see this.

[vtjnash]

cygwin-to-mingw, llvm35

here's how you can invoke it directly

julia> f() = Base.box(Ptr{Void}, Intrinsics.jl_alloca(10000)) # something bigger than 4096

julia> code_llvm(f,())

; Function Attrs: uwtable
define i8* @julia_f42236() #0 {
top:
  %0 = alloca [10000 x i8], align 1, !dbg !8
  %.sub = getelementptr inbounds [10000 x i8]* %0, i64 0, i64 0
  ret i8* %.sub, !dbg !8
}

julia> f()
LLVM ERROR: Program used external function '___chkstk_ms' which could not be resolved!
Segmentation fault

[tkelman]

Yep, nevermind, confirmed. Must just happen later in the numbers test than the other failure I've been seeing.

[vtjnash]

probably just needs an entry like

julia/src/codegen.cpp

Line 4569 in cc075cf

resetstkoflw_func = Function::Create(FunctionType::get(T_void, false),

(with signature void __chkstk_ms(void)), although it has some other possible names on various platforms: __chkstk_ms, _chkstk, _alloca, _chkstk,

[tkelman]

For reference https://github.com/llvm-mirror/llvm/blob/0378ed43685cc7343e487bceddf14f119578fcc0/lib/Target/X86/X86FrameLowering.cpp#L378-L393

llvm-mirror/llvm@da44c36

[vtjnash]

i've tried to fix this as I suggested, but it seems the compiler/linker only includes this function if it feels like it?

[vtjnash]

nevermind, i was doing the symbol mangling wrong

[vtjnash]

@Keno it appears that this requires a custom lowering pass, resulting in it getting called out explicitly as an i32 PCrel call. this is correct when emitted into a static binary, but not as useful when JIT.

--- a/lib/Target/X86/X86InstrControl.td
@@ -290,9 +290,9 @@ let isCall = 1, isCodeGenOnly = 1 in
   // ___chkstk(Mingw64): clobber R10, R11, RAX and EFLAGS, and update RSP.
   let Defs = [RAX, R10, R11, RSP, EFLAGS],
       Uses = [RSP] in {
-    def W64ALLOCA : Ii32PCRel<0xE8, RawFrm,
-                      (outs), (ins i64i32imm_pcrel:$dst),
-                      "call{q}\t$dst", [], IIC_CALL_RI>,
                     Requires<[IsWin64]>, Sched<[WriteJump]>;
   }

i'm not sure what is supposed to go there, however. or maybe we need to start actually moving the __chkstk function all over the place (or at least a jmp trampoline to it)?

thoughts?

[vtjnash]

for temporary use, it works if i just disable the offending code:

diff --git a/lib/Target/X86/X86ISelLowering.cpp b/lib/Target/X86/X86ISelLowering.cpp
index f154bd6..1f93c92 100644
--- a/lib/Target/X86/X86ISelLowering.cpp
+++ b/lib/Target/X86/X86ISelLowering.cpp
@@ -20915,29 +20915,10 @@ X86TargetLowering::EmitLoweredWinAlloca(MachineInstr *MI,
   // non-trivial part is impdef of ESP.

   if (Subtarget->isTargetWin64()) {
-    if (Subtarget->isTargetCygMing()) {
-      // ___chkstk(Mingw64):
-      // Clobbers R10, R11, RAX and EFLAGS.
-      // Updates RSP.
-      BuildMI(*BB, MI, DL, TII->get(X86::W64ALLOCA))
-        .addExternalSymbol("___chkstk")
-        .addReg(X86::RAX, RegState::Implicit)
-        .addReg(X86::RSP, RegState::Implicit)
-        .addReg(X86::RAX, RegState::Define | RegState::Implicit)
-        .addReg(X86::RSP, RegState::Define | RegState::Implicit)
-        .addReg(X86::EFLAGS, RegState::Define | RegState::Implicit);
-    } else {
-      // __chkstk(MSVCRT): does not update stack pointer.
-      // Clobbers R10, R11 and EFLAGS.
-      BuildMI(*BB, MI, DL, TII->get(X86::W64ALLOCA))
-        .addExternalSymbol("__chkstk")
-        .addReg(X86::RAX, RegState::Implicit)
-        .addReg(X86::EFLAGS, RegState::Define | RegState::Implicit);
       // RAX has the offset to be subtracted from RSP.
       BuildMI(*BB, MI, DL, TII->get(X86::SUB64rr), X86::RSP)
         .addReg(X86::RSP)
         .addReg(X86::RAX);
-    }
   } else {
     const char *StackProbeSymbol = (Subtarget->isTargetKnownWindowsMSVC() ||
                                     Subtarget->isTargetWindowsItanium())

[Keno]

This may have been fixed upstream in http://reviews.llvm.org/rL227519.

[tkelman]

On 3.7, yeah? Should keep an eye on the 3.6 branch to see whether it gets backported. If not we can probably carry the patch locally if we use 3.6.

[SimonDanisch]

Guess this is not completely fixed on cygwin:

reduce.jl
intset.jl
dict.jl
iterator.jl
inference.jl
LLVM ERROR: Program used external function '___chkstk_ms' which could not be resolved!
LLVM ERROR: Program used external function '___chkstk_ms' which could not be resolved!
error during bootstrap:
RtlLockHeap at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
RtlEnterCriticalSection at C:\WINDOWS\SYSTEM32\ntdll.dll (unknown line)
utf8proc_NFKC at C:\cygwin64\home\S\julia\usr\bin\libjulia.dll (unknown line)
utf8proc_NFKC at C:\cygwin64\home\S\julia\usr\bin\libjulia.dll (unknown line)
utf8proc_NFKC at C:\cygwin64\home\S\julia\usr\bin\libjulia.dll (unknown line)
utf8proc_NFKC at C:\cygwin64\home\S\julia\usr\bin\libjulia.dll (unknown line)
utf8proc_NFKC at C:\cygwin64\home\S\julia\usr\bin\libjulia.dll (unknown line)
utf8proc_NFKC at C:\cygwin64\home\S\julia\usr\bin\libjulia.dll (unknown line)
jl_generate_fptr at /home/S/julia/src\codegen.cpp:749
jl_trampoline_compile_function at /home/S/julia/src\builtins.c:968
jl_apply_generic at /home/S/julia/src\gf.c:1676
unknown function (ip: 0000000007BE00EE)
jl_apply_generic at /home/S/julia/src\gf.c:1651
jl_f_apply at /home/S/julia/src\builtins.c:486
unknown function (ip: 000000000C0625D4)
jl_apply at /home/S/julia/src\julia.h:1262
unknown function (ip: 000000000C061220)
jl_apply at /home/S/julia/src\julia.h:1262
unknown function (ip: 000000000C060699)
jl_apply at /home/S/julia/src\julia.h:1262
unknown function (ip: 0000000008FB8DB7)
jl_apply at /home/S/julia/src\julia.h:1262
unknown function (ip: 0000000007FC0A27)
jl_apply at /home/S/julia/src\julia.h:1262
unknown function (ip: 000000000AA5009E)
jl_apply at /home/S/julia/src\julia.h:1262
unknown function (ip: 000000000A6F1CFC)
jl_apply_generic at /home/S/julia/src\gf.c:1651
unknown function (ip: 000000000A6B0FF8)
jl_apply at /home/S/julia/src\julia.h:1262
unknown function (ip: 000000000A1D0B00)
...

commit 50cf353

System: Windows (x86_64-w64-mingw32)
  CPU: Intel(R) Core(TM) i5-4200U CPU @ 1.60GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)

[tkelman]

LLVM version .?

[SimonDanisch]

Ah yeah, 3.6.0

[tkelman]

Can you tell whether or not that was built including the patch from https://github.com/JuliaLang/julia/blob/master/deps/win64-allocas-llvm-3.6.0.patch ? I think we got those patches backported for 3.6.1, should also be in 3.6.2. Or release_37 branch is in RC mode so should hopefully be slow-moving until 3.7.0 is ready?