similar to: Possible stack corruption during call to JITSymbol::getAddress()

Displaying 20 results from an estimated 1000 matches similar to: "Possible stack corruption during call to JITSymbol::getAddress()"

2017 Apr 17
2
Possible stack corruption during call to JITSymbol::getAddress()
Hi David, This looks like bad eh-frame data due to a failure to fix up the frame descriptor entries: <debug: adding frame> EHFrameAddr: 0x7feae5827000, EHFrameLoadAddr: 0x00000000e5827000, EHFrameSize: 60 ==64588==ERROR: AddressSanitizer: SEGV on unknown address 0x7feae5827020 (pc 0x7feae886d970 bp 0x000000000001 sp 0x7ffca10e75f8 T0) Eyeballing the code in RuntimeDyldELF (vs
2017 Apr 20
2
Possible stack corruption during call to JITSymbol::getAddress()
Hi David, Thanks very much for that. I'll continue to dig in as time permits, and I'll update the bug report with my progress once it's filed. Cheers, Lang. On Mon, Apr 17, 2017 at 6:42 PM, David Lurton <dlurton at gmail.com> wrote: > Thanks Lang. I think I'll go the bug creation route. I have an email out > to llvm-admin requesting an account on bugs.llvm.org.
2017 May 01
1
Possible stack corruption during call to JITSymbol::getAddress()
Hi David, Sorry to hear. Has anyone followed up with you yet? I've continued to dig in to this in my spare time and I've found the issue. It's a use-after-free, rather than any sort of memory smashing. ORC is currently failing to deregister the EH-frame section when the JIT is torn down (but *is* deallocating the memory for it). Normally that's not disastrous (though it does
2017 May 07
2
[cfe-dev] JIT doens't resolve address - Resolve obj-Addresses?
Hi Bjoern, CCing cfg-dev (since that's where the conversation started) and llvm-dev (since it's relevant there). Do you know if there is a way to obtain the fully resolved obj-code? I > wanted to load the functions into a shared memory, but how? The only thing > I receive is a function pointer, but I don't know how large the function > 'behind' is. Even a call to
2017 Aug 06
2
Compile issues with LLVM ORC JIT
I tree to compile the LLVM ORC JIT examples. But I'm stuck in some problems I can't solve my own. First at all I compile with C++14 enabled with latest stable LLVM and clang, this means 4.0.1. I get the following error. Do I missed some specific compile option? Compilation looks like this here. |CompilingcontribJIT.cpp PWD:/home/ikuehl/projects-llvm/TurboLisp/domainEngineer
2015 Mar 13
4
[LLVMdev] Thoughts about ExecutionEngine/MCJIT interface
Hi, I think ExecutionEngine as a common interface for both Interpreter and MCJIT is almost useless in the current form. There are separated methods in ExecutionEngine for similar or the same features provided by Interpreter and MCJIT, i.e. to get a pointer to function you should call getPointerToFunction() for Interpreter or getFunctionAddress() for MCJIT. Personally, I'm using MCJIT and
2018 Jun 28
3
Since MCJIT I can't get libm functions to work
I am upgrading our JIT application to use LLVM 6.0.0, and with this transition I am making the move to use the new MCJIT facility. A problem I am encountering is that the math functions from libm are not resolved/found. I am using the lambda resolver from the KaleidoscopeJIT class which first searches the present modules and, if that is unsuccessful, continues the search in the whole process
2018 Jun 28
2
Since MCJIT I can't get libm functions to work
Hi Alex, loading the symbols explicitly helped. With this the build process doesn't need any additional linker flags. Very nice. Thanks, Frank On 06/28/2018 04:38 PM, Alex Denisov wrote: > Hi Frank, > > If I am not mistaken it doesn't look in the whole process space by default. > Please, try loading all the symbols explicitly: > >
2017 Nov 14
1
OrcJIT + CUDA Prototype for Cling
Hi Lang, thank You very much. I've used Your code and the creating of the object file works. I think the problem is after creating the object file. When I link the object file with ld I get an executable, which is working right. After changing the clang and llvm libraries from the package control version (.deb) to a own compiled version with debug options, I get an assert() fault. In void
2016 Apr 01
2
Kaleidoscope on Windows - bug maybe found?
To try to find out why it was crashing, I followed the trail of function calls: C:\llvm\examples\Kaleidoscope\Orc\initial\toy.cpp auto ExprSymbol = J.findUnmangledSymbol("__anon_expr"); JITSymbol findUnmangledSymbol(const std::string Name) { return findSymbol(mangle(Name)); } JITSymbol findSymbol(const std::string &Name) { return CompileLayer.findSymbol(Name,
2017 Sep 27
2
OrcJIT + CUDA Prototype for Cling
Dear LLVM-Developers and Vinod Grover, we are trying to extend the cling C++ interpreter (https://github.com/root-project/cling) with CUDA functionality for Nvidia GPUs. I already developed a prototype based on OrcJIT and am seeking for feedback. I am currently a stuck with a runtime issue, on which my interpreter prototype fails to execute kernels with a CUDA runtime error. === How to use the
2019 Mar 22
2
MCJIT, can't use with math functions
Hi, for my application (uses Builder and MCJIT) I am making the transition LLVM 6.0 -> 8.0. It runs fine for self-contained functions, but whenever a jit-ed function contains calls to the math library (e.g. @cosf) it seems to have problems getting the address after successfully finding the symbol: Failure value returned from cantFail wrapped call UNREACHABLE executed at
2019 Sep 23
4
"Freeing" functions generated with SimpleORC for JIT use-case
Hi all, I am using LLVM for JIT use-case and compile functions on the fly. I want to "free" the modules after some time and reclaim any memory associated with it. I am using the SimpleORC API <https://llvm.org/docs/tutorial/BuildingAJIT1.html> now. Is there an API to "free" all the memory associated with the module? I use one "compiler" instance (think similar
2019 Sep 19
3
"corrupted size vs. prev_size" when calling ExecutionSession::lookup()
Hi, I wrote a compiler that generate IR code and run it on the JIT, and there randomly crashed due to "corrupted size vs. prev_size" depends on the IR code generated from the source code. Here's how I created the JIT: llvm::InitializeNativeTarget(); llvm::InitializeNativeTargetAsmPrinter(); llvm::InitializeNativeTargetAsmParser(); // create jit llvm::orc::ExecutionSession
2017 Feb 06
3
Kaleidoscope tutorial: comments, corrections and Windows support
Hi, I'm currently working my way through the tutorial with LLVM 3.9.1 on Windows (finished chapter 4) and stumbled over a few things which could be improved: - "LLVMContext" does not exist as a variable -> "TheContext" - Chapter 3: 5 times - Chapter 4: 1 time - Chapter 5: 4 times - Chapter 6: 2 times - Chapter 7: 2 times 3.4. Function Code
2017 Sep 22
2
Question regarding GlobalMappingLayer in LLVM 5
Hi, I'm attempting to port some code which uses the GlobalMappingLayer in the Orc JIT. This code worked fine in LLVM 4, but I'm getting a compile error with LLVM 5. I think the problem is that this layer hasn't been modified to account for some of the changes made in LLVM 5, but I wanted to make sure that I wasn't missing something. I have code which looks like this:
2019 May 10
2
ORC - which example code?
Trying to put together a simple test JIT compiler, using ORC which as I understand it will be the supported API going forward, I noticed that in the first chapter of the updated Kaleidoscope tutorial, there is sample code that starts like this: ExecutionSession ES; RTDyldObjectLinkingLayer ObjectLayer; IRCompileLayer CompileLayer; DataLayout DL; MangleAndInterner Mangle; ThreadSafeContext Ctx;
2016 May 17
3
External function resolution: MCJIT vs ORC JIT
When using ORC JIT, I'm having trouble with external function resolution (that is, of a function defined in the app, with C linkage). I add a declaration for the function to my IR, and when I use MCJIT, it finds it and all is well, But when I use ORC JIT (I *think* correctly, at least it closely matches what I see in the tutorial), I get an LLVM error, "Program used external function
2017 Sep 28
0
Question regarding GlobalMappingLayer in LLVM 5
Hi Brian, Yes - I believe you're correct. I'm working on a fix and extra test coverage now. In the meantime, I believe you should be able to fix the signatures in your copy and everything should "just work". Cheers, Lang. On Fri, Sep 22, 2017 at 2:04 PM, Brian Kahne via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > > > I’m attempting to port
2017 Aug 24
1
Invalid Signature of orc::RTDyldObjectLinkingLayer::NotifyLoadedFtor
Hi all, hi Lang It's a little late to report issues for release_50, but I just found that thing while porting my JitFromScratch examples to 5.0. This is a really nifty detail, but (if I'm not mistaken) the function signature of RTDyldObjectLinkingLayer::NotifyLoadedFtor is incorrect: $ grep -h -r -A 1 "using NotifyLoadedFtor"