search for: jit'd

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 library load/unloa...

Hmm, I'm confused. The DSO is compiled with gcc. Do I need to compile it with clang instead? I don't believe the JITted code uses the thread support library directly, although I suppose it may be hidden with templates and/or inline functions... On Mon, Sep 28, 2020 at 10:43 PM Lang Hames <lhames at gmail.com> wrote: > > Hi Geoff, > > If you want to access the variable directly from JIT'd co...

...39;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 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 library l...

Hi, I put the sample code and a brief analysis using Valgrind to GitHub in order to make my problem clear. https://github.com/naosuke/how-to-free-memory-of-JIT-function The Valgrind heap profiler indicates memory leaking but I don't get what is wrong with the way to free memory. If someone could please offer some advice/suggestion on this, I would really appreciate it. Best, Naosuke On Thu, Dec 29, 2011 at 6:58 PM, OKUDA Naosuke <okudanaosuke at...

Hi, I'm testing how to free memory of a JIT'd function. I thought ExecutionEngine::freeMachineCodeForFunction() and Function::eraseFromParent() would work and did a test with the following sample code. But I found that the memory usage of the process is constantly growing as the while loop goes. Could someone shed light on this please?...

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; }; class...

Probably not well. But it depends on the application, and probably the loader. Some applications (OpenCL comes to mind) have the bitcode ready to go as soon as they start. The only reason they use the JIT is because they want to compile the code to run fast on the available hardware. It really depends on how often the application wants to generate code, which for some people may not be that often. This is a new model that doesn't really fit with the current interface, but it could be made to w...

On 22 May 2013, at 13:23, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > Why the private message? If unintentional, please forward this to the list. Ooops, forgot to hit reply-all. Didn't the LLVM lists used to default to reply-to-list behaviour? > So, the JIT is analogous to dlopen, so it should be using general > dynamic and local dynamic models. It is only the initial exec and > local exec that require the dynamic linker to allocate memory at > startup. The dynamic linker will have allocated the memory because the TLS variable in question is...

...{}catch(...){}', then it should run the d'tors for you. There's no reason for you to have a "run_dtors" function there. > > How does the C++ implementation "know" to run the d'tors for me since the C++ objects that were created on the stack were created by JIT'd code, first via alloca to allocate StructTypes of the right size (char[sizeof(T)]) then calling a thunk of the form: > > extern "C" void thunk_item_M_new( void *addr ) { > new( addr ) item; > } > > where "addr" is the address returned by alloca? T...

There may be another explanation, but I've seen this sort of issues before: LLVM uses several object pools (associated w/ LLVM context and JIT engine), and often objects from these pools are leaked, or the pools grow infinitely due to implementation bugs. These are not an ordinary memory leaks, as destroying the LLVM context and/or JIT engine will successfully reclaim all the memory. The problem is only visible for long-running JIT proce...

...> Bar b; > mux(b); // may throw an exception. > } catch (...) { > // The d'tor for 'b' is called before the code is is executed. > } > } Except I don't have code like that. Again, the object is *not* constructed by a normal function, but a JIT'd function. Since LLVM knows nothing about C++ or destructors, I certainly have to call the destructor manually, e.g., obj->~Class();, for the case where no exception is thrown. My JIT'd code looks like: %item = type { [16 x i8] } %singleton_iterator = type { [24 x i8] } %add_iterator...

I've been trying to get oprofile results for jitted code without success. I built an 3.5.0 llvm with oprofile enabled, and tested it with lli on a small test case. I built the latest oprofile from the git repository. Debugging I can see that lli is registering the listener and making the oprofile calls to the libopagent api to specify the names...

...he correct way of implementing this is to have one physical page mapped to two locations in virtual memory. One is writeable, the other is read + execute. This does not defeat the point of W^X, because you must find both pointers to be able to exploit it, rather than just one. This is really how JIT'd memory maps should be created on all platforms, as it allows you to use the memory without significant fragmentation (i.e. you don't need a whole page per function) and it makes it much harder to exploit the JIT'd code. David

Hi, I am wondering how I can get the JIT'd llvm IR during VMKit execution. I am stuck in precompiling phase (when loading library classes), and I am facing various problems. If I can log the JIT'd llvm IR (from Java bytecode), that would be convenient. I turned on --enable-debug, but it doesn't seem very helpful at this s...

...; mux(b); // may throw an exception. >> } catch (...) { >> // The d'tor for 'b' is called before the code is is executed. >> } >> } > > Except I don't have code like that. Again, the object is *not* constructed by a normal function, but a JIT'd function. Since LLVM knows nothing about C++ or destructors, I certainly have to call the destructor manually, e.g., obj->~Class();, for the case where no exception is thrown. My JIT'd code looks like: > > %item = type { [16 x i8] } > %singleton_iterator = type { [24 x i8]...

...e 'try{}catch(...){}', then it should run the d'tors for you. There's no reason for you to have a "run_dtors" function there. How does the C++ implementation "know" to run the d'tors for me since the C++ objects that were created on the stack were created by JIT'd code, first via alloca to allocate StructTypes of the right size (char[sizeof(T)]) then calling a thunk of the form: extern "C" void thunk_item_M_new( void *addr ) { new( addr ) item; } where "addr" is the address returned by alloca? To me, it would seem that if yo...

Hello, I've been trying to use LLVM's Orc JIT from C API for a few days and i can't get it to work, I'm kind of annoyed for the lack of documentation examples for the C API. Here's my code: https://hasteb.in/ohexiweb.cpp I compile it using clang `llvm-config --cflags --ldflags --libs all` main.c -o main -g -rdynamic And it ends...

To recap, on Mar 14, 2012, I wrote: > 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_iterator { > public: > virtual ~item_iterator(); > virtual bool next( item *result ) = 0; > }; > > I'm aware that LLVM doesn't know an...

Mi Maurice, A follow up to Andy's comments: MCJIT can find line numbers for ELF files, at least in limited circumstances. I know because I broke the regression test for it while doing some cleanup recently. ;) Looking at lib/ExecutionEngine/OProfileJIT/OProfileJITEventListener.cpp, I see the line: // TODO: support line number info (similar to In...

Cheers Lang! You were right, I was testing this on Linux. I was planning on committing these changes with the corresponding changes to the Kaleidoscope tutorial walk-through. Might be a bit of a surprise to have no explanation of what MCJITHelper and friends is doing. I'll try and make time to prepare some patches along these lines, as well as updating future chapters with the same fix. Thanks for taking a look :) Charlie. On 16 January 2015 at 19:46, Lang Hames <lhames at gmail.com> wrote: > Committed in r226308. Tha...