similar to: [LLVMdev] [Patch] Clean up DynamicLibrary

I've got a number of problems with this patch. First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. Second, unless I'm reading it wrong, this relies on static constructors. That causes headaches and is against the

The various ExecutionEngine pieces may be the only places within LLVM that are using the DynamicLibrary stuff, but there's no telling what various LLVM consumers may be using it for. The "stat" symbols shouldn't be exposed the way they are in the old JIT memory manager location. It's not clear to me why that didn't happen inside getPointerToNamedFunction there. Is

On 11/11/13 17:42, Kaylor, Andrew wrote: > I've got a number of problems with this patch. > > First, we have plans to pry apart the remaining strands connecting JIT with MCJIT, so I don't want to do anything that reconnects them. That is, I'm against moving things from RTDyldMemoryManager into ExecutionEngine. The direction of LLVM is not something I'm in a position to

Is there documentation somewhere on how to call external functions from llvm? The only guide I found was this: http://www.gearleaf.com/blog/post/44, and it doesn't seem to be working for me. I have a function: llvm::GenericValue lle_X_create_number_object(llvm::FunctionType* ft, const std::vector<llvm::GenericValue>& args) { llvm_object_structure* result = new

Thanks for splitting up the patch. I'm not the right person to comment on the modification and access time changes (though it looks alright to me). You might want to re-submit that part on its own as it's likely to be ignored by people who aren't interested in JIT stuff otherwise. Regarding the memory manager changes, functionally this looks good. I'm not a big fan of macros,

Well, is the attached version better? I've extended the RTDyldMemoryManager hooks instead to pick up the ARM math functions statically, and left JITMemoryManager alone except for changing the conditional so that it will build with non-glibc libraries. I've also split the original patch up into two parts, to separate the math function fixes from setLastModificationAndAccessTime. The

Oh, I see now. It turns out that even knowing what the end goal was I misunderstood part of what the macros were doing. If you could add some comments explaining what the macros are doing then I guess I can live with the patch in this form. I definitely agree that it's better not to have two copies of the list. Thanks, Andy -----Original Message----- From: James Lyon [mailto:jameslyon0

You are adding the symbol as "lle_X_create_number_object" yet your error message implies you have tried to lookup and use "create_number_object". Can you provide the code for the lookup? On 20/08/2010, at 8:07 AM, Alec Benzer wrote: > Is there documentation somewhere on how to call external functions from llvm? The only guide I found was this:

Committed as r194832. -----Original Message----- From: James Lyon [mailto:jameslyon0 at gmail.com] Sent: Thursday, November 14, 2013 4:58 PM To: Kaylor, Andrew; LLVM Dev Subject: Re: [LLVMdev] Android JIT patch Here's an updated version with more comments. James On 14/11/13 23:06, Kaylor, Andrew wrote: > Oh, I see now. It turns out that even knowing what the end goal was I

Hi everybody, I just updated to the latest svn trunk version, but now the code does not compile anymore. It trows an error in "f:\dev\llvm\lib\system\Win32/DynamicLibrary.inc(159) : error C2228: left of '.find' must have class/struct/union". Below you can find the small patch which makes the compiler happy again :-) Sincerely yours Marius Wachtler

Well, the reason I did it that way was that the list of functions is fairly long and has to be written out twice; once to declare the functions and once to do the if(Name==#fn) bit, and I thought nested macros was simpler than having two copies of the list. On 14/11/13 22:07, Kaylor, Andrew wrote: > Thanks for splitting up the patch. I'm not the right person to comment on the

I've attached a patch which has got JIT compilation working (for me at least!) on Android. It turns out that the problem was a bunch of intrinsic __aeabi* functions which reside in libgcc.a rather than libc.so so are not available unless explicitly linked in, so it's rather similar to the StatSymbols hack. I moved the StatSymbols code into ExecutionEngine.cpp rather than

Unless I'm missing something, indeed addGlobalMapping should not work with MCJIT. MCJIT does not consult EEState.getGlobalAddressMap when resolving symbols. Instead it uses RTDyldMemoryManager::getSymbolAddress which checks with DynamicLibrary::SearchForAddressOfSymbol, so Andy's suggestion of DynamicLibrary::addSymbol is better as it should work with both JIT and MCJIT. Another options

Here's an updated version with more comments. James On 14/11/13 23:06, Kaylor, Andrew wrote: > Oh, I see now. It turns out that even knowing what the end goal was I misunderstood part of what the macros were doing. > > If you could add some comments explaining what the macros are doing then I guess I can live with the patch in this form. I definitely agree that it's better not

The blog post I linked to implied that adding a symbol in the form lle_X_FUNCTIONNAME would allow you to call a function called FUNCTIONNAME. Is this not the case? On Thu, Aug 19, 2010 at 6:46 PM, <o.j.sivart at gmail.com> wrote: > You are adding the symbol as "lle_X_create_number_object" yet your error > message implies you have tried to lookup and use

Not really. I'm pretty much leaving the win32 directory up to Jeff Cohen these days. I don't have a way to replicate the problem. Reid. On Wed, 2004-12-29 at 12:46, Henrik Bach wrote: > Reid, > > I'm just curious to know if these errors are on your new year list :) > ---------------- > make[1]: Entering directory `/C/projects/build/MinGW/llvm-1-1/lib/System' >

Hi, I am trying to implement a scenario similar to running ExceptionDemo.cpp with parameter -1 (where the JITed code calls the C++ function which throws an exception) Different from the given example I am using IRParser instead of IRBuilder. I can successfully catch the exception in Linux but the program crashes in Mac and Windows. The code is similar to as follows: ### The test.cpp :

I have no way of duplicating mingw problems either, but in this case the fix is obvious and has been committed. Reid Spencer wrote: >Not really. I'm pretty much leaving the win32 directory up to Jeff Cohen >these days. I don't have a way to replicate the problem. > >Reid. > >On Wed, 2004-12-29 at 12:46, Henrik Bach wrote: > > >>Reid, >>

Reid, I'm just curious to know if these errors are on your new year list :) ---------------- make[1]: Entering directory `/C/projects/build/MinGW/llvm-1-1/lib/System' llvm[1]: Compiling DynamicLibrary.cpp for Debug build In file included from c:/projects/src/llvm-1/llvm/lib/System/DynamicLibrary.cpp:25: c:/projects/src/llvm-1/llvm/lib/System/win32/DynamicLibrary.cpp:22: warning:

I'm using llvm::sys::DynamicLibrary to export Symbols from my host-application to a JIT instance. Now I was wondering what the scope of this DynamicLibrary is, because I think I never attached it to the JIT or the module. Would it be possible to use the exported symbols even from a separate process (e.g. a forked off JIT), as long as the host app is running? -Frank