search for: getpermanentlibrari

On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: > Nick, > I have uploaded the full walk with 'set env DYLD_PRINT_INITIALIZERS'. It didn't seem very informative > as the dyld error occurs right after... > > (gdb) > llvm::sys::DynamicLibrary::getPermanentLibrary (filename=0x142903da8 "/sw/opt/llvm-3.2/lib/LLVMPolly.so", errMsg=0x7fff5fbfe6e0) at

On Mon, Oct 22, 2012 at 11:40:32AM -0700, Nick Kledzik wrote: > > On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: > > > Nick, > > I have uploaded the full walk with 'set env DYLD_PRINT_INITIALIZERS'. It didn't seem very informative > > as the dyld error occurs right after... > > > > (gdb) > >

On Sun, Oct 21, 2012 at 06:00:36PM -0700, Nick Kledzik wrote: > Jack, > > Some binary has an initializer which dyld is calling. Somehow the initializer gets to: > #4 0x0000000100f3b2c0 in Json::Value::maxUInt () > which is calling a function in another dylib for the first time. When you call a function in another dylib, you actually jump through a (lazy) pointer. The pointer

On Mon, Oct 22, 2012 at 09:48:59AM -0400, Jack Howarth wrote: > On Sun, Oct 21, 2012 at 06:00:36PM -0700, Nick Kledzik wrote: > > Jack, > > > > Some binary has an initializer which dyld is calling. Somehow the initializer gets to: > > #4 0x0000000100f3b2c0 in Json::Value::maxUInt () > > which is calling a function in another dylib for the first time. When you

On Oct 23, 2012, at 12:50 PM, Jack Howarth wrote: > On Mon, Oct 22, 2012 at 11:40:32AM -0700, Nick Kledzik wrote: >> >> On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: >> >>> Nick, >>> I have uploaded the full walk with 'set env DYLD_PRINT_INITIALIZERS'. It didn't seem very informative >>> as the dyld error occurs right after...

Hi, We need to support unloading of shared libraries. I'd like to continue using sys::DynamicLibrary. Few questions: * Is there a fundamental reason not to implement UnloadLibrary? * Would it be necessary to implement some fancy symbol use-check for unloading, or would it be fine to make this a "use at your own risk" operation? At least as a first implementation? * I would also

Nick, While enhancing the fink llvm32 packaging to support the polly tool, I ran into a dyld failure when the dragonegg plugin tries to load LLVMPolly.so plugin... dyld: lazy symbol binding failed: fast lazy bind offset out of range (39257, max=7640) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin11.4.2/4.7.2/cc1 dyld: fast lazy bind offset out of range (39257, max=7640) in image

On Mon, Oct 22, 2012 at 10:17:56AM -0700, Nick Kledzik wrote: > Jack, > > I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: > > dyld: fast lazy bind offset out of range (53437, max=7640) in image

Kaylor, do you have some good documented example code which shows the usage of the MCJIT ? This would help a lot ... the sematic of lots of API calls are not intuitively understandable. Best Regards --Armin Kaylor, Andrew wrote: > I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an

Hi, I'm building LLVM IR. I'd like to compile this IR to native code (I don't want JIT) and immediately load it to execute. So far, I've the following: 1) I can emit the IR to native assembly/object file doing the same thing llc does (using TargetMachine::addPassesToEmitFile). 2) I can dynamically load a precompiled .so file (using llvm::sys::DynamicLibrary::getPermanentLibrary),

I'm not sure I understand your use case, but MCJIT (as opposed to the legacy JIT) does almost exactly what you're asking for. It generates an in-memory object file image (using addPassesToEmitMC) and then loads and links it for execution. If there's some particular detail you don't like in the way this is happening, you might be able to generate a file as you have and then use

Daniel, I didn't find the MCJIT directory under unitests/ExecutionEngine ... there is only a directory called JIT. You mean this directory ? Many thanks --Armin Malea, Daniel wrote: > Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT > > The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. > >

Jack, Some binary has an initializer which dyld is calling. Somehow the initializer gets to: #4 0x0000000100f3b2c0 in Json::Value::maxUInt () which is calling a function in another dylib for the first time. When you call a function in another dylib, you actually jump through a (lazy) pointer. The pointer initially points to a helper which loads an index parameter specifying which function to

Take a look at the MCJIT unit tests under unittests/ExecutionEngine/MCJIT The MCJITTestBase class does the majority of the interactions with the LLVM API you're referring to. Good luck, Dan On 2012-10-13, at 4:57 AM, "Armin Steinhoff" <as at steinhoff-automation.com> wrote: > > Kaylor, > > do you have some good documented example code which shows the usage of

Hi, > I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: > > dyld: fast lazy bind offset out of range (53437, max=7640) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 > > means the initializer

On Tue, Oct 23, 2012 at 01:05:04PM -0700, Nick Kledzik wrote: > On Oct 23, 2012, at 12:50 PM, Jack Howarth wrote: > > On Mon, Oct 22, 2012 at 11:40:32AM -0700, Nick Kledzik wrote: > >> > >> On Oct 22, 2012, at 11:34 AM, Jack Howarth wrote: > >> > >>> Nick, > >>> I have uploaded the full walk with 'set env

Jack, I looks like the code is calling dlopen() on LLVMPolly.so and it or something it links against has an initializer. The initialer is run before dlopen() returns and the crash is in the initializer. The message: dyld: fast lazy bind offset out of range (53437, max=7640) in image /sw/lib/gcc4.7/libexec/gcc/x86_64-apple-darwin12.2.0/4.7.2/cc1 means the initializer called something which

It's definitely there. It was added in r165246 recently so you probably have an older version. Amara On 13 October 2012 23:02, Armin Steinhoff <as at steinhoff-automation.com> wrote: > Daniel, > > I didn't find the MCJIT directory under unitests/ExecutionEngine ... there > is only a directory called JIT. > You mean this directory ? > > Many thanks > >

Hi, Has anyone succeeded in building llvm on AIX? Currently I am investigating several tools for code analyses and I came upon Clang. We at CCV run our core business applications on RS6000/AIX. At our department we develop those applications. The reviews on clang look very promising. I was able to build and run it on Linux (SuSE 12.1) without any problems. I tested it with valgrind sources and

Tim Northover wrote: > Hi Baris, > >> If I could produce a .so file in step 1, my problem would be solved. llc has a "-relocation-model=pic" option, but the file produced with that did not dynamically load. > That relocation-model=pic option usually necessary for a linker to be > able to produce a .so file (it changes how variables are addressed so > that more things