search for: dynamiclinker

Hello llvmdev, (just for fun) I've tried to compile LLVM under cygwin. With "make -k" I got only: ----------------- DynamicLinker.cpp: In function `void* GetAddressOfSymbol(const char*)': DynamicLinker.cpp:40: error: `RTLD_DEFAULT' undeclared (first use this function) DynamicLinker.cpp:40: error: (Each undeclared identifier is reported only once for each function it appears in.) ----------------- well, the...

...'ve tried to compile LLVM under cygwin. > With "make -k" I got only: Cool. We don't rountinely use this configuration, so there may be a bit of leg work you'll have to do... :) But that said, we would love to get LLVM working cleanly on it! > ----------------- > DynamicLinker.cpp: In function `void* GetAddressOfSymbol(const char*)': > DynamicLinker.cpp:40: error: `RTLD_DEFAULT' undeclared (first use this > function) > DynamicLinker.cpp:40: error: (Each undeclared identifier is reported only once > for each function it appears in.) > --------...

...ends an underscore to the symbol, which means that if you are >> looking for main(), you ask for "main" and it looks for "_main", which >> is how the symbols are named in Mach-O. >> This could be the source of a problem - how does GetAddressOfSymbol in >> DynamicLinker.cpp use dlsym? > > I believe that GetAddressOfSymbol is only used by the JIT. The -load > mechanism just dlopens a shared object. Shared objects for plugins > have > static constructors (".init" section) that are supposed to autoregister > the pass when the plugin is...

...timization module. The implementation will use ltdl library > if its available, otherwise it tries to use dlopen/dlsym if they are > available, otherwise you get a compile time warning and (void*)0 if you > try to look up a symbol. Okay, interesting. How hard would it be to replace the DynamicLinker.cpp functionality with your code? > I'm not sure about the libtool implementation but it does more than just > accommodate the platform differences for the interface function names. > It also makes sure that platform requirements for initialization of the > loaded module, etc. are...

...- on OS X, it automatically prepends an underscore to the symbol, which means that if you are looking for main(), you ask for "main" and it looks for "_main", which is how the symbols are named in Mach-O. This could be the source of a problem - how does GetAddressOfSymbol in DynamicLinker.cpp use dlsym? Does it assume anything about the symbol names? #include <dlfcn.h> // dlcompat int main(int argc, const char **argv){ void *obj = dlopen(argv[1], RTLD_NOW | RTLD_GLOBAL); void * sym = dlsym(obj,argv[2]); printf("done: obj was %x sym was %x %s\n", obj, sym ,...

Solved. Short version: You don't need to change DynamicLinker.cpp at all. dlopen() should just work, except that the defaults for libtool are to produce the wrong kind of shared object. On OS X, libtool needs to be passed the -module option to create dlopen-able objects: % diff Makefile.rules.old Makefile.rules 326c326 < Link := $(LIBTOOL) --mo...

...ically > prepends an underscore to the symbol, which means that if you are > looking for main(), you ask for "main" and it looks for "_main", which > is how the symbols are named in Mach-O. > This could be the source of a problem - how does GetAddressOfSymbol in > DynamicLinker.cpp use dlsym? I believe that GetAddressOfSymbol is only used by the JIT. The -load mechanism just dlopens a shared object. Shared objects for plugins have static constructors (".init" section) that are supposed to autoregister the pass when the plugin is loaded. I don't know anyt...

The DynamicLibrary.cpp code is written and I believe it to be complete, but it hasn't been tested much (at all). llvm-ld uses it to load its plug-in optimization module. The implementation will use ltdl library if its available, otherwise it tries to use dlopen/dlsym if they are available, otherwise you get a compile time warning and (void*)0 if you try to look up a symbol. I'm not sure

...;t see whether it was resolved. Also, this is on Mac > OS X, and the previous question was about Linux. The problem is that this has not been implemented yet on Mac OSX. If you're familiar with the OS/X interfaces for loading .so files, it should be pretty easy. Take a look at lib/Support/DynamicLinker.cpp. I think that OS/X doesn't have windows.h :), and it also doesn't have dlopen. If you can provide the necessary magic for your platform, it should just work. -Chris > This problem happens with the Hello pass, so I'll use that to > illustrate. I'm using LLVM 1.2. &gt...

Hi, I can't get opt to list (in -help) passes that I load using -load. I see in the list archives that a similar problem has been brought up before but I didn't see whether it was resolved. Also, this is on Mac OS X, and the previous question was about Linux. This problem happens with the Hello pass, so I'll use that to illustrate. I'm using LLVM 1.2. The plugin loads with no

...emory by destroying the ExecutionEngine that was created for each "JITDylib". Should I do the same with ExecutionSessions? For reference, here's the short bit of code I'm playing with for linking with ORC: https://github.com/halo-project/llvm/blob/master/compiler-rt/lib/halomon/DynamicLinker.h#L55 Thanks, Kavon -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190819/ae346237/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type:...

Hi, Sorry if you've seen this message before on llvm.discourse.group or elsewhere -- I've been trying to get to the bottom of this for a while now and asked about this in a few different platforms before. I'm currently trying to debug a bug in a LLVM-generated Wasm code. The bug could be in the code that generates LLVM (rustc) or in the LLVM, I'm not sure yet. LLVM IR and Wasm

...e their work (cross your fingers :). > Is there code that needs to be ported to os x so it can profile itself? The only thing that LLVM is missing on OS/X (besides a code generator) that I'm aware of is support for dynamic plugin loading (Brian would know more). If you look in lib/Support/DynamicLinker.cpp, you'll see some stuff that is only defined for HAVE_DLOPEN. It would be very handy to get support for OS/X, which doesn't have the dl* family of syscalls. -Chris -- http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/

> > There are two problems with this: 1) there is no JIT for PPC yet, so > LLVM will use the interpreter (which is intolerably slow and has other > issues). 2) Spec compiles the executables in one place and them moves > them to another, but it only copies the shell script and not the > bytecode file, so you get that error message. > > The normal solution to this problem

wasm-ld is currently unable to link a shared wasm library (generated with `wasm-ld --shared`) with .o files and produce a working executable. I'm curious if there's a fundamental reason for this, or is this simply something that wasn't needed and could be implemented if needed. I think this could be done by - Resolving "GOT.mem" and "GOT.func" imports and

...File > + RelativePath="..\..\include\llvm\Support\Debug.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\DOTGraphTraits.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\DynamicLinker.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\ELF.h"> > + </File> > + <File > + RelativePath="..\..\include\llvm\Support\FileUtilities.h"> > + </File> > + <File > +...

Hi, when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches m. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: win32patches.txt URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20041115/34634455/attachment.txt>

...r/local/llvm-2.8/include/llvm/Support/DataFlow.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/Debug.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/DebugLoc.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/Dwarf.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/DynamicLinker.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/ELF.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/ErrorHandling.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/FileUtilities.h -- Installing: /usr/local/llvm-2.8/include/llvm/Support/Format.h -- Installing: /usr/local/...

On Thu, Sep 30, 2010 at 3:08 PM, Samuel Williams <space.ship.traveller at gmail.com> wrote: > Hi, > > I might just be doing something stupid, but when I do > > $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. > $ sudo make install > > I don't get the expected headers in >        /usr/local/llvm-2.8/include/llvm > > It is

Hi, I might just be doing something stupid, but when I do $ cmake -DCMAKE_INSTALL_PREFIX=/usr/local/llvm-2.8 -DCMAKE_BUILD_TYPE=Release .. $ sudo make install I don't get the expected headers in /usr/local/llvm-2.8/include/llvm It is simply an empty directory. What am I doing wrong? This is on Mac OS X, CMake 2.8+ Kind regards, Samuel