similar to: [LLVMdev] Migration from JIT to MCJIT

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

? 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

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

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

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

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

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

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

On Thu, Mar 7, 2013 at 6:33 PM, Jiong Wang <jiwang at tilera.com> wrote: > Hi all, > > Updated the patches for TILE-Gx backend: > > 1. added initial regression tests for tilegx codegen. > 2. added initial regression tests for MC Layer. > 3. fixed those commenting style issues. > > please review, thanks. This is a huge patch, and reviewing it in tar.gz is hard. To

Hi Chris, could you please comment on committing TILE-Gx backend into community? ========== TILE-Gx Status =========== Features Supported === 1. general function. 2. PIC/TLS/JumpTable. 3. Instructoin Bundling for VLIW. 4. Asm Parser 5. MC Layer (aware of instruction bundle), MCJIT support. 6. Initial regression tests for CodeGen & MC Layer. Regression Result === Expected Passes : 13363

on 2013/3/23 1:52, Chris Lattner wrote: > On Mar 19, 2013, at 8:58 PM, Jiong Wang <jiwang at tilera.com> wrote: > >> Hi Chris, >> >> could you please comment on committing TILE-Gx backend into community? > Hi Jiong, > > I don't have any special advice here. It sounds like the general functionality level is high enough. Taking it into mainline sounds

On Mar 19, 2013, at 8:58 PM, Jiong Wang <jiwang at tilera.com> wrote: > Hi Chris, > > could you please comment on committing TILE-Gx backend into community? Hi Jiong, I don't have any special advice here. It sounds like the general functionality level is high enough. Taking it into mainline sounds great, so long as it is reviewed by someone. -Chris > > >

On 03/08/2013 04:48 AM, Dmitri Gribenko wrote: > On Thu, Mar 7, 2013 at 6:33 PM, Jiong Wang <jiwang at tilera.com> wrote: >> Hi all, >> >> Updated the patches for TILE-Gx backend: >> >> 1. added initial regression tests for tilegx codegen. >> 2. added initial regression tests for MC Layer. >> 3. fixed those commenting style issues. >>

On 03/23/2013 10:51 AM, Jiong Wang wrote: > on 2013/3/23 1:52, Chris Lattner wrote: >> On Mar 19, 2013, at 8:58 PM, Jiong Wang <jiwang at tilera.com> wrote: >> >>> Hi Chris, >>> >>> could you please comment on committing TILE-Gx backend into community? >> Hi Jiong, >> >> I don't have any special advice here. It sounds like the

On 03/02/2013 04:50 AM, Dmitri Gribenko wrote: > You also need tests for Clang bits, too. > > Mechanical issues: > > +/// getTileRegisterNumbering - Given the enum value for some register, > +/// return the number that it corresponds to. > > Please don't duplicate function and class name in comments. Existing > code does this, but current style guidelines advise not

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 all, Updated the patches for TILE-Gx backend: 1. added initial regression tests for tilegx codegen. 2. added initial regression tests for MC Layer. 3. fixed those commenting style issues. please review, thanks. I have tried to understand the new backend requirement for LLVM from the mailiing list archive, it's sure TILE-Gx backend will be actively maintained & improved, it's

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

Hi, On behalf of Tilera Corporation, I'd like to contribute llvm ports to Tilera's TILE-Gx architecture and wish this could be submitted to main llvm tree. TILE-Gx is a VLIW architecture with 64-bit registers, 64-bit address space, and 64-bit instructions. TILE-Gx has load-store architecture ISAs. More information on the architectures is available at

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