similar to: [LLVMdev] What is the scope of the DynamicLibrary?

Is there a way to intercept the calls to abort() or exit(), specifically ? Disabling all external symbol resolution seems not really feasable since I need some std libs. -Frank 2010/7/19 Garrison Venn <gvenn.cfe.dev at gmail.com> > You could use shared memory or the equivalent of UNIX domain sockets. On a > UNIX system, you will also probably want to catch > SIGCHLD along with

Hi Alex, loading the symbols explicitly helped. With this the build process doesn't need any additional linker flags. Very nice. Thanks, Frank On 06/28/2018 04:38 PM, Alex Denisov wrote: > Hi Frank, > > If I am not mistaken it doesn't look in the whole process space by default. > Please, try loading all the symbols explicitly: > >

You could use shared memory or the equivalent of UNIX domain sockets. On a UNIX system, you will also probably want to catch SIGCHLD along with implementing "nowait" handling behavior in the parent. This is of course a low level approach. Higher level libraries that you may be using, or other OSs may provide their own wrappers. Garrison On Jul 19, 2010, at 4:05, Frank Fuchs wrote:

Ok, thank you for your explanation. Is it possible for forked processes to share data? Especially for the child process to send some data to the parent? -Frank 2010/7/18 Nick Lewycky <nicholas at mxc.ca> > Frank Fuchs wrote: > >> Hi, >> >> I'm doing some tests concerning the embedding of LLVM and clan in my >> application. >> Now I stumbled across

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' >

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:

>> llvm::sys::DynamicLibrary::LoadLibraryPermanently(nullptr) This is one is a bit tricky and hard to find. I spent quiet some time digging into MC and ORC JIT execution engines trying to find what makes them work. The problem is that this trick (LoadLibraryPermanently) happens inside of EngineBuilder, despite that the functionality belongs to a JIT engine itself, not to the builder. I

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

Hi, Attached patch moves code around; it should not have a functional effect. It formalizes a few concepts that were spread over several files before, depending on platform. It removes historical leftovers. Symbol lookup now happens in three easy phases, on all platforms: * explicitly provided symbols through AddSymbol() * shared libraries * platform provided "special" symbols. No

I don't know since when, but this file has been changed to remove all the trickery (aka defines) needed for MinGW-w64 (and probably everything else that as forgotten) to succesfully compile it. Attached is a patch that reintroduces the compiler checking. I would like to see this in LLVM 3.0, otherwise (by the looks of the reintroduced code) anything newer than _MSC_VER_1500 will be broken.

Hi Larry, Thanks so much! This seems to do the trick. I would have spun my wheels for > a long time before discovering all of this, wow. No worries. :) I'll try to keep this in mind and make sure I address it in future Kaleidoscope tutorial chapters - these issues tripped me up the first time I encountered them too. Do I even want to know what additional chickens need to be sacrificed

On Fri, 2004-12-31 at 05:30, Francisco Puentes wrote: > Hi again, and thanks (Reid) for your fast response: Glad to help. > > Yes, it works!!! Only changing the order of libraries in the Makefile. Great! > > Nowaday I have my software with the capability of compile assembly, bytecode > (from buffer and file) and link them with a set of libraries. It seems to > work

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,

The interpreter still resolves printf using a hack. It does try to use DynamicLibrary to find it, but fails. DynamicLibrary on Windows only searches the main program executable for symbols, lli.exe in this case. As the C/C++ runtime is in a DLL, it won't find printf in lli.exe. It ought to then search the runtime DLL, the name of which depends on how the binaries are built, but it

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

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

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

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

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