search for: __chkstk

It's not a solution to the actual bug (which is, as the thread you linked discusses, a problem with the assumption on LLVM's part that the __chkstk function lies within 2GB of the emitted code's address space) but there is a simple workaround: hoist all allocas to the first basic block of your function. This allows the JIT to perform all stack allocations in a single adjustment of the SP instead of needing to use dynamic stack allocation,...

...CE add dword ptr [rcx+40h],2 0000000581D300D2 mov rsp,rbp 0000000581D300D5 pop rbp 0000000581D300D6 ret The function located at 0x00000005F08425D0 is not valid (according to visual studio: 00000005F08425D0 ?? ??). If I compile LLVM bytecode using llc, this function is __chkstk: .def fn_0000000000000000; .scl 2; .type 32; .endef .text .globl fn_0000000000000000 .align 16, 0x90 fn_0000000000000000: # @fn_0000000000000000 # BB#0: # %bb push rbp...

Maybe we should also change the stack probing code. I think ___chkstk_ms is used since gcc 4.6. It simplifies the prologue generation code a bit. Regards, Kai On 10.12.2013 02:18, Rafael Espíndola wrote: > Mingw switched abis with the release of gcc 4.7 > (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now > mingw (like msvc) given this...

I would think that the R_X86_64_PC32 relocation type should never be generated with large code model since large code model, by definition, makes no assumptions about the size or address of sections. The use of win32-elf might throw a wrinkle into this, since that is a code path that probably isn't exercised much outside of MCJIT use. That said, when this assertion fails it is usually

...org> wrote: > On 11/30/2018 8:31 AM, Stefan Kanthak via llvm-dev wrote: >> Hi @ll, >> >> compiler-rt implements (for example) the MSVC (really Windows) >> specific routines compiler-rt/lib/builtins/i386/chkstk.S and >> compiler-rt/lib/builtins/x86_64/chkstk.S as __chkstk_ms() >> See <http://msdn.microsoft.com/en-us/library/ms648426.aspx> >> >> Is there any special reason why compiler-rt doesn't implement >> other MSVC specific functions (alias builtins or "compiler >> intrinsics") for which clang/LLVM but generates...

I figured it out. I was using this implementation of __chkstk from compiler-rt: DEFINE_COMPILERRT_FUNCTION(___chkstk) push %rcx cmp $0x1000,%rax lea 16(%rsp),%rcx // rsp before calling this routine -> rcx jb 1f 2: sub $0x1000,%rcx test %rcx,(%rcx) sub $0x1000,%rax cmp...

...com> wrote: > >> > >> On Tue, Aug 5, 2014 at 8:53 AM, John Kåre Alsaker > >> <john.mailinglists at gmail.com> wrote: > >>> > >>> Would the __probestack functions be a suitable addition to compiler-rt? > >>> Does it already have __chkstk or is that provided by something else on > >>> Windows? I noticed that libgcc implemented them in cygwin.S. > >> > >> > >> It seems reasonable to put them in compiler-rt/lib/builtins. > >> > >> I don't think anyone is currently using comp...

...Tue, Aug 5, 2014 at 7:34 PM, Reid Kleckner <rnk at google.com> wrote: > On Tue, Aug 5, 2014 at 8:53 AM, John Kåre Alsaker < > john.mailinglists at gmail.com> wrote: > >> Would the __probestack functions be a suitable addition to compiler-rt? >> Does it already have __chkstk or is that provided by something else on >> Windows? I noticed that libgcc implemented them in cygwin.S. >> > > It seems reasonable to put them in compiler-rt/lib/builtins. > > I don't think anyone is currently using compiler-rt's builtins on Windows, > so it does...

...empty, this can be a signal that the check must be emitted inline, either as > a sequence of stores or a loop. > > This also addresses David's concern with the hardcoded __probestack symbol > name. First of all, LLVM should be free to choose how it does stack probes, it could call ___chkstk_ms, ___chkstk_ms, __chkstk, _alloca, _chkstk, __probestack or any other stack probe function it knows about, it could unroll and inline it for smaller allocation amounts, it could inline the function entirely or it could do nothing, for platforms which does stack overflow checks in hardware. I don...

Mingw switched abis with the release of gcc 4.7 (http://gcc.gnu.org/gcc-4.7/changes.html). The main change is that now mingw (like msvc) given thiscall calling convention to methods by default. I think the last bug blocking us to support the new abi has just been fixed. The question now is how to switch. The attached patches simply switch llvm and clang to the new ABI. This is similar to what

...id Kleckner <rnk at google.com> wrote: >> >> On Tue, Aug 5, 2014 at 8:53 AM, John Kåre Alsaker >> <john.mailinglists at gmail.com> wrote: >>> >>> Would the __probestack functions be a suitable addition to compiler-rt? >>> Does it already have __chkstk or is that provided by something else on >>> Windows? I noticed that libgcc implemented them in cygwin.S. >> >> >> It seems reasonable to put them in compiler-rt/lib/builtins. >> >> I don't think anyone is currently using compiler-rt's builtins on Wind...

...eck must be emitted inline, > either as > > a sequence of stores or a loop. > > > > This also addresses David's concern with the hardcoded __probestack > symbol > > name. > First of all, LLVM should be free to choose how it does stack probes, > it could call ___chkstk_ms, ___chkstk_ms, __chkstk, _alloca, _chkstk, > __probestack or any other stack probe function it knows about, it > could unroll and inline it for smaller allocation amounts, it could > inline the function entirely or it could do nothing, for platforms > which does stack overflow checks...

Viktor, could you try my patch? I guess they are __chkstk. http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120220/137577.html ...Takumi

Would the __probestack functions be a suitable addition to compiler-rt? Does it already have __chkstk or is that provided by something else on Windows? I noticed that libgcc implemented them in cygwin.S. On Mon, Aug 4, 2014 at 9:08 PM, Philip Reames <listmail at philipreames.com> wrote: > > On 08/01/2014 05:38 PM, John Kåre Alsaker wrote: > > On Fri, Aug 1, 2014 at 11:12 PM, P...

Hi, Attempting to use LLVM in jitting mode for AMD64, we met a problem. When the jitted routine needs a big stack frame (> 1 page), the system attempts to call __chkstk to probe the stack. This attempt results in assertion in RuntimeDyldELF::resolveX86_64Relocation(), case ELF::R_X86_64_PC32, because the RealOffset does not fit in 32 bits. Same happens with __alloca (when IRBuilder::CreateAlloca appears in a conditional block). Perhaps the issue can be fixed by u...

This is the right fix if Cygwin wants calls to __chkstk. Otherwise you'll want TargetTriple.isOSMSVCRT(). On Wed, Oct 23, 2013 at 2:50 AM, Yaron Keren <yaron.keren at gmail.com> wrote: > If it's a Windows-only thing the correct tests would be: > > if (NumBytes >= 4096 && STI.isOSWindows()) { > > and > &gt...

...ld be: if (NumBytes >= 4096 && STI.isOSWindows()) { and if (Subtarget->isTargetWindows()) where bool isOSWindows() const { return TargetTriple.isOSWindows(); } Yaron 2013/10/23 Andrew MacPherson <andrew.macp at gmail.com> > Glad that helped! As I understand it __chkstk is always required on > Windows regardless of output type, I had meant to file a bug about this but > had apparently forgotten to do so. I think the check needs to be that the > target is Windows and ignore the output type, Linux and OSX don't use this. > > Cheers, > Andrew &g...

Hi everyone! I've faced a strange problem after updating to Windows 8 Consumer Preview recently. It seems that LLVM inserts 4 calls to the same function at the start of generated code. The function's disassembly (taken from nearby computer with Windows 7) is: 00000000773A0DD0 sub rsp,10h 00000000773A0DD4 mov qword ptr [rsp],r10 00000000773A0DD8 mov qword ptr

...inside LLVM. Could anyone tell me what LLVM code in ExecutionEngine is responsible for allocating and protecting memory for generated native functions? Best regards, Victor Milovanov. 2012/3/2 NAKAMURA Takumi <geek4civic at gmail.com>: > Viktor, could you try my patch? I guess they are __chkstk. > > http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20120220/137577.html > > ...Takumi

I suspect that there are 2 issues here: * I have incorrect alignment somewhere * MSVC / .pdb / CodeView debugging is not working correctly. I think the latter would help solve the former. I will send out a new email later talking about the issues I'm having debugging llvm-generated binaries with MSVC. On Sat, Sep 30, 2017 at 3:33 PM, Andrew Kelley <superjoe30 at gmail.com> wrote: