similar to: [LLVMdev] MC and admisible function names

Hi Óscar, I'm not aware of any intentional function name limitations with MCJIT. It's entirely possible that something somewhere is rejecting the name for one reason or another (intentionally or otherwise). When you call getPointerToFunction in MCJIT, it will ultimately call RuntimeDyldImpl::getSymbolLoadAddress to look the name up in a table of known function names. That table gets

Hello Andy, "Kaylor, Andrew" <andrew.kaylor at intel.com> writes: > I'm not aware of any intentional function name limitations with MCJIT. > It's entirely possible that something somewhere is rejecting the name > for one reason or another (intentionally or otherwise). Yep, apparently those names with characters outside the acceptable range of the object file

> So I'm using "llvm/ExecutionEngine/MCJIT.h" instead of > "llvm/ExecutionEngine/JIT.h", and I've added setUseMCJIT(true) to > EngineBuilder, but what actually happens is: > > LLVM ERROR: Target does not support MC emission! > > Do I need to do anything else? IIRC, this error might be due to not linking against the MCJIT library component. Add the

Hi Lang, Yeah, I remember this case. Basically what’s happening is that there are relocations for ELF on x86 that use a value that is present in the object image as part of the calculation for the final value that goes in the same location. If you ever find yourself applying relocations for a second time (for instance, because the loaded object location is remapped for out-of-proc execution)

Hi, I'm migrating my code (running on mac) from using JIT to MCJIT. My code generates in memory, mostly using the llvm-c api, and then runs the generated code. When I try to use MCJIT I encounter a problem with relocations of external symbols – functions compiled statically beforehand with gcc. I get the following error: Invalid relocation type! UNREACHABLE executed at

Following along from lli code, if you add a call to InitializeNativeTargetAsmPrinter() during setup, it gets a bit farther and crashes rather than issuing that error. (Rebuilding with debugging symbols now to dig into it further…) -matt Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000000 0x000000010000349e in

It’s pretty intermittent at the moment…sometimes I get the relocation overflow issue, sometimes I get another issue about BSS sections having no contents. The source code to reproduce either is simple: #include <iostream> int main (int argc, char* argv[]) { } I’ve managed to reproduce the BSS section issue in clang consistently, and since that comes before terms of where it happens in

Ah, now that makes sense. Guess I was a little over-eager with my bugreport. Thanks! :) However, I am now running into the same Problem as Matt ("Target does not support MC emission!"). Best, Ralf Am 25.08.2011 19:32, schrieb Bruno Cardoso Lopes: > Hi Ralf, > > FYI, old JIT doesn't support AVX at all, no encoding info, etc... The > only way to use AVX+JIT is using

Yes, I’m handling all internal and external relocations manually in NotifyLoadedFtor and I already verified that I get the behavior I need if I comment out the call to resolveRelocations. I would like to reuse ObjectLinkingLayer::addObjectSet (which eventually calls RuntimeDyld::loadObject), which has the right calls to the memory manager and also RuntimeDyld::registerEHFrames. I understand that

Oops, sorry for the spam. That last comment was incorrect. It’s IMAGE_REL_AMD64_REL32 not _5 > On 5 Oct 2015, at 17:26, Joshua Gerrard <joshua.gerrard at roli.com> wrote: > > Additional info: when the relocation issue does occur the relocation type is IMAGE_REL_AMD64_REL32_5 > >> On 5 Oct 2015, at 17:16, Joshua Gerrard <joshua.gerrard at roli.com> wrote: >>

That's great news, thanks! If I can be of any help, let me know. :) I'll see if I can reduce the example for the relocation issue whilst you're at it. Regards, Joshua -- Joshua Gerrard JUCE Software Developer *ROLI’s **award-winning* <http://www.telegraph.co.uk/luxury/design/31520/the-seaboard-grand-piano-wins-designs-of-the-year-2014-award.html>* Seaboard GRAND, celebrated

This replaces the build dependency on perl with one on awk which is already used in the build system and is much more ubiquitous than perl --- Makefile.in | 2 +- mkproto.awk | 39 +++++++++++++++++++++++++++++++++++++++ mkproto.pl | 48 ------------------------------------------------ 3 files changed, 40 insertions(+), 49 deletions(-) create mode 100644 mkproto.awk delete mode 100644

Hi Lang, It turns out I also need an ability to tell the object linking layer not to apply any relocations. I need to skip this step below. The only way I can see I can achieve that is by creating my own ObjectLinkingLayer that would duplicate almost all of orc::ObjectLinkingLayer. I’d like to avoid that. An alternative it to pass a flag to orc::ObjectLinkingLayer constructor and

Hi, Thanks for your ideas. Memory allocation already exceeds 2x64K in the "working" case so it's not the condition of allocating more than 64K. To be sure I had modified SectionMemoryManager::allocateSection to allocate four time the required memory but it did not trigger more crashes.I debugged through the allocation code including the Win32 code and it seems to work well. I have

Hi Ralf, FYI, old JIT doesn't support AVX at all, no encoding info, etc... The only way to use AVX+JIT is using MCJIT, which contains the correct encoding, but unfortunately the framework isn't good yet as the old one is. On Thu, Aug 25, 2011 at 10:12 AM, Ralf Karrenberg <Chareos at gmx.de> wrote: > Hi Matt, > > I am unsure about MCJIT, but I guess the problem is the same.

virt-v2v obviously cannot convert this kind of devices, since they are specific to the host of the hypervisor. Thus, emit a warning about the presence of direct network interfaces, so at least this can be noticed when converting a guest. --- v2v/parse_libvirt_xml.ml | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/v2v/parse_libvirt_xml.ml b/v2v/parse_libvirt_xml.ml index

Correct or no I don't know, but this change will affect all x86-64 targets including Linux and Windows as getMaxStubSize() is called from the ELF linker as well as the Mach-O linker. 2013/10/15 Christian Schafmeister <chris.schaf at verizon.net> > > With the help of iain at codesourcery.com and andrew.kaylor at intel.com we > tracked the problem down to a bad relocation that

Hi, There may be two problems with __register_frame usage. However based on http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061768.html I think the existing code is correct for OS-X but likely buggy for Linux and Windows systems. Your crash is on OS-X, right? Anyhow, the first problem is very easy to fix. On Linux and Windows (at least) __register_frame should be called once and not

Hi, This is a question on how to resolve weak symbols from the binary for symbols that are also llvm::Module-local. Currently, the JIT seems to favor resolving to module-local symbols over existing symbols: $ cat symbols.cxx extern "C" int printf(const char*,...); template <class T> struct StaticStuff { static T s_data; }; template <class T> T

Hi Eugene, Skipping the call to resolveRelocations would disable many (if not all) internal relocations too. Is that the desired behavior? At that point there's not much left for RuntimeDyld (or the ObjectLinkingLayer) to do. Would something like a NoopLinkingLayer be a workable solution? Cheers, Lang. On Wed, Jul 22, 2015 at 7:26 PM, Eugene Rozenfeld < Eugene.Rozenfeld at