similar to: [LLVMdev] x86 vs. i386 in clang ang llvm

Andrew, I've attached a small reproduction of the issue. Reproduce by: $ /usr/bin/g++ `llvm-config --cxxflags` -g -m32 -c mcjit_external_symbol.cpp $ /usr/bin/g++ `llvm-config --ldflags` -g -m32 -o mcjit_external_symbol mcjit_external_symbol.o `llvm-config --libs all` $ ./mcjit_external_symbol verifying... LLVM ERROR: Program used external function '_external' which could not be

Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla record for this problem. -Andy From: Weiss, Eran [mailto:Eran.Weiss at emc.com] Sent: Thursday, April 11, 2013 12:40 AM To: Kaylor, Andrew Cc: llvmdev at cs.uiuc.edu; Jim Grosbach; Jiong Wang Subject: Re: [LLVMdev] Migration from JIT to MCJIT Andrew, I've attached

Existing clients (LLDB) deal with externals by resolving them to constant function pointers that are referenced in the IR. That’s obviously ugly as hell, but it gets things done. The old JIT was able to simplify things because it assumed the JITed code was running in the same process as the JIT compiler. The MCJIT doesn’t assume that, so it has to handle more possibilities. For example, that the

Eran, Is there any chance you could boil this down to a small reproducer? I’ve got a mid-to-long-term goal of getting rid of the ugliness in LLDB that Jim mentioned, and fixing your problem would be a good first step. Thanks, Andy From: Jim Grosbach [mailto:grosbach at apple.com] Sent: Wednesday, April 10, 2013 4:19 PM To: Kaylor, Andrew; Jiong Wang Cc: Weiss, Eran; llvmdev at cs.uiuc.edu

Thank you for the help. The relocation type value is anded with 0xffffffffL. (RuntimeDyldMachO.cpp:214) Maybe this mask should be different? Anyway, it seems like this relocation isn't implemented. (RuntimeDyldMachO.cpp:104) From: Jiong Wang <jiwang at tilera.com<mailto:jiwang at tilera.com>> Date: Tue, 9 Apr 2013 09:42:03 -0400 To: Eran Weiss <eran.weiss at

Hi, I'm having problems when trying to JIT IR generated from C++ with clang. My code resides in a dynamically loaded shared object, and crashes when I call getPointerToFunction, claiming that it encountered a pseudo instruction. Interestingly, a very similar code that run as a separate executable JITing the same IR works fine. Note that I have not have modified LLVM. Any suggestions what

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

? 2013/4/9 21:08, Weiss, Eran ??: > 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

Hi, I have a problem with JIT code generation on mac. The LLVM-IR I have is fine, but the machine code generated crashes. I see two instructions "add %al,(%eax)" (which are four 0 bytes, numerically) prior to function calls. As eax holds the pointer to the called function, this crashes with SIGBUS. These instructions don't make sense in the context of the code, which is why

The MachO handling isn’t always straightforward in that it has a lot of bit fields to handle while it’s also trying to accommodate the format abstractions baked into the interfaces. The actual relocation type gets extracted in the RuntimeDyldMachO::resolveRelocation function (RuntimeDyldMachO.cpp:32) before it is passed on to the architecture-specific handlers. So the mask you mentioned is

For anyone encountering this problem in the future, the cause of this problem was debugging symbols (-g) given to clang when generating IR. On 20/05/2012 12:21, "Weiss, Eran" <Eran.Weiss at emc.com> wrote: >Hi, > >I'm having problems when trying to JIT IR generated from C++ with clang. >My code resides in a dynamically loaded shared object, and crashes when I

Thanks Martin, I'm generating the code using LLVM (writing llvm::Triple myself and llvm::TargetRegistry::lookupTarget is working), and that's how my bitcode is generated then using LLC to cross-compile that. So using armv7-win32-msvc is getting me a bit closer, but what CPU, raspberry pi 3 is running a Cortext-A53, but when I specify that in -mcpu argument I get this error: > llc.exe

Submitted to bugzilla as PR 15729 From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Kaylor, Andrew Sent: Thursday, April 11, 2013 1:13 PM To: Weiss, Eran Cc: llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] Migration from JIT to MCJIT Thanks, Eran. I’m not sure how soon I’ll have a solution for you, but it’s on my to-do list now. I’ll also create a bugzilla

Is there a way to use LLC to cross-compile some code to run on Windows IOT on Raspberry Pi ? I was able to convince LLVM to spit out some bitcode for this, but when I try llc it dumps: llc.exe test.bc -o test.obj -filetype=obj -O3 -mtriple=aarch64-win32-msvc -mcpu=cortex-a53 Wrote crash dump file "C:\Users\clovett\AppData\Local\Temp\llc.exe-4990d8.dmp" 0x0000000000000000

Hello, While trying to find out why the LDC compiler refuses to generate object code for MSP430 targets (but generates MSP430 assembly or LLVM IR/bitcode), I came across the following apparent inconsistency. This works: $ clang --target=msp430 -c test.c This doesn't work: $ clang --target=msp430 -S -emit-llvm test.c $ llc -filetype=obj test.ll /opt/msp430/bin/llc: target does not support

W dniu 2012-10-26 16:55, Daniel Kłobuszewski pisze: > Hello, > > Recently I found binaries produced with LLVM impossible to debug under > Windows. This was probably related to the following bug: > http://llvm.org/bugs/show_bug.cgi?id=13636 > > Asm generated from .ll files revealed that some offsets to debug > information were incorrect: they were absolute instead of

Hello, I'm working on a binary translator project that emits an .ll file. I'm trying to debug it in Visual Studio and would like to be able to step through and see my generated .ll file in the debugger. Does LLVM support debug information corresponding to an input .ll file? My hunch is "no, as it expects debug info to come from Clang." I assemble it using: llc -filetype=obj

On Jan 21, 2013, at 3:12 PM, Chandler Carruth <chandlerc at google.com> wrote: > On Mon, Jan 21, 2013 at 2:59 PM, Andrew Trick <atrick at apple.com> wrote: > > On Jan 21, 2013, at 12:37 PM, Chandler Carruth <chandlerc at google.com> wrote: > >> On Mon, Jan 21, 2013 at 11:49 AM, Andrew Trick <atrick at apple.com> wrote: >> Moving to llvmdev...

Hi LLVMdev, Does the latest trunk code support Windows Phone 8.1 target ? I was trying out a simple program, but Visual Studio 2013's linker failed for me with this error - app.obj : error LNK2008: Fixup target is not aligned 'add3' This is what I tried - * Download latest LLVM sources (as on 4th June) and build them on my MAC 10.9 machine. * Wrote a simple a.c, with add3

Hi llvm-community, I use llc (3.4-final) to generate object file: *llc code.bc -mtriple=x86_64-pc-win32-elf -mcpu=x86-64 -filetype=obj -code-model=large -o=code.o* then I load it with *RuntimeDyld + SectionMemoryManager* in my app. I faced the problem described in 15356 <http://llvm.org/bugs/show_bug.cgi?id=15356>bug. Debug assertion fails at