similar to: [LLVMdev] JIT question about resolving unknown function calls

On Jun 29, 2009, at 3:37 AM, Carter Cheng wrote: > > My understanding is that the JIT system allows during the running of > the system resolution of call instructions to undefined functions to > be trapped and then patched with the correct address (is this true?). Yes, see: http://llvm.org/docs/tutorial/LangImpl4.html#jit > The question I have is does the current system also

Hi, Whilst doing some QA work on XORP on my desktop, which has fxp0 and msk0, fxp0 got totally hosed. I was running PIM-SM and IGMPv2 router-mode on the box at the time. I wonder if this is related to the problems with fxp multicast transmission I saw back in April. I'm a bit concerned about this as fxp is still a very widespread and useful network chip. I am running

Hi All, I just implemented an often-requested feature: the ability to delete machine code out of the JIT's code buffer (the ExecutionEngine::freeMachineCodeForFunction(F) method). The implementation uses a very general free-list mechanism for tracking free ranges in the buffer, and it works perfectly in my simple test cases designed to cover all of the code paths. However, I don't

Hi Chris, > If you don't *know* that all (e.g.) function pointers to this code are > dead (which means that execution could come back to the function), you > should use the ExecutionEngine::recompileAndRelinkFunction(F) method. recompileAndRelinkFunction() overwrites the old machine code with a branch to the new. Is it always guaranteed that there's space to write the new

On Tue, Jul 6, 2010 at 9:08 AM, Greg Clayton <gclayton at apple.com> wrote: >> 2) Can I easily debug JIT'd code with LLDB? > > Are you running JIT'd code within another process that can be debugged (i.e. the simulation binary)? If so, you might want to have LLVM generate a full blown dylib, not just a JIT'd chunk of code and load the dylib using the standard shared

Wouldn't it mean each time a function is compiled it would need to be bundled to its own dylib? How well would that scale? Félix Le 2010-07-07 à 15:41:18, Reid Kleckner a écrit : > On Tue, Jul 6, 2010 at 9:08 AM, Greg Clayton <gclayton at apple.com> wrote: >>> 2) Can I easily debug JIT'd code with LLDB? >> >> Are you running JIT'd code within another

My project has a C++ library that I want to allow the user to use via some programming language to be JIT'd to call functions in said library. For the sake of simplicity, assume the library has classes like: class item { public: item(); item( int ); ~item(); // ... }; class item_iterator { public: virtual ~item_iterator(); virtual bool next( item *result ) = 0; };

We are trying to adapt the clang-llvm interpreter code here<http://llvm.org/viewvc/llvm-project/cfe/trunk/examples/clang-interpreter/> to run some c++ code that uses stl vector and c++ string among other things. This resulted in a number of unresolved symbols, and after eliminating a bunch of them, we are still stuck with __Unwind_resume and __assert_fail I would really appreciate any help

<cc'ing llvmdev> On Tue, 28 Nov 2006, Eric van Riet Paap wrote: > I'm working on using the LLVM JIT in PyPy and I hop you can give me a few > hint. ok > I have some things working at and try to write C++ code for what I need > from Python. The unittest I am working on at the moment is looks like > this > > --- Python code... > llglobalmul4 =

On Fri, 12 May 2006, Ralph Corderoy wrote: >> If you don't *know* that all (e.g.) function pointers to this code are >> dead (which means that execution could come back to the function), you >> should use the ExecutionEngine::recompileAndRelinkFunction(F) method. > > recompileAndRelinkFunction() overwrites the old machine code with a > branch to the new. Is it

I ask for advice, for TheExecutionEngine === NULL, >> Which result's in a null-pointer for "TheExecutionEngine"; which >> explains the bus-errror .. Reid Kleckner wrote: > Try changing the above line to: > std::string str; > TheExecutionEngine = > EngineBuilder(OurModuleProvider).setErrorStr(str).create(); > cout << str << '\n';

I've been following this guide: http://llvm.org/docs/tutorial/LangImpl4.html and am getting an error when trying to create an execution engine. When running this code: executionEngine = llvm::EngineBuilder(module).setErrorStr(&errStr).create(); errStr contains: "Interpreter has not been linked in." I'm using this command to build: g++ -g errors.o lexer.o parser.o lang.o

Is it possible to write a .pdb file containing the debug info stored in a COFFObjectFile once the NotifyObjectEmitted is triggered by the JIT compiler ? -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180308/3c25cddd/attachment.html>

>> <snip>. >> void add_global_mapping(const char* name, void* address) { >> GlobalVariable var(Type::IntTy, false, >> GlobalVariable::ExternalLinkage, 0, name, gp_module); >> gp_execution_engine->addGlobalMapping(&var, address); >> } > > This is creating a new global variable on the stack, instead of > finding the existing

On Fri, Mar 9, 2018 at 7:00 PM Lang Hames <lhames at gmail.com> wrote: > Hi Vivien, > > I'm not familiar with Windows development, but I believe you could dump > the object file to disk then run LINK.EXE to produce the PDB. > Alternatively, I think LLD can also produce PDB files (Rui -- is that > right?), in which case you may be able to use that. > Yes, lld can

Hi All, Just a couple of updates this week: First: there is a preview patch up at https://reviews.llvm.org/D75838 to enable use of JITEventListeners in RTDyldObjectLinkingLayer. I've only done very preliminary testing on it, but was able to debug simple JIT'd programs on Linux using the GDB registration listener. If you've been wanting to move to ORC but held up by lack of debugger /

> On 13 Feb 2018, at 17:42, Stanislav Pankevich <s.pankevich at gmail.com> wrote: > > On Tue, Feb 13, 2018 at 12:18 PM, David Chisnall > <David.Chisnall at cl.cam.ac.uk> wrote: >> On 12 Feb 2018, at 22:31, Stanislav Pankevich via llvm-dev <llvm-dev at lists.llvm.org> wrote: >>> >>> Specifically I explored the latest objc4-723 >>>

Hi Yafei, As david told, you can make the symbols of your host process visible to the JIT'd code through DynamicLibrarySearchGenerator::getForCurrentProcess. On Thu, 19 Sep 2019 at 00:46, David Blaikie via llvm-dev < llvm-dev at lists.llvm.org> wrote: > +Lang Hames <lhames at gmail.com> , JITer of JITs. > > I believe there's some kind of resolver you can add that

Hey list, I'm looking for information on how programs that span multiple LLVM modules work at runtime, especially wrt. symbol handling when running in a JIT setting. To give some background, I'm developing a language that targets LLVM as a backend, and I'd like my translation units to map to LLVM modules as closely as possible. What I'm looking for here is something similar to

Hi Chris, thanks for your answers! [large executables] > It depends on what you're building. A release build of LLVM (make > ENABLE_OPTIMIZED=1, with the results in llvm/Release) is > significantly smaller than a debug build. Even with that, however, > the binaries are larger than they should be (5M?). Noone has spent > the time to track down why this is to my