similar to: [LLVMdev] Alternative to Linker::LinkInFile()

Hi Tom, >From the context I am assuming you are in a JIT context, so the comments about using a platform specific LTO mechanism don't apply. Were you using this code to extract bitcode files from archives, or just to link in an individual bitcode file? - Daniel On Wed, Feb 13, 2013 at 12:24 PM, Tom Stellard <tom at stellard.net> wrote: > Hi Daniel, > > In r172749 you

On Thu, Feb 14, 2013 at 04:41:41PM -0800, Daniel Dunbar wrote: > Hi Tom, > > From the context I am assuming you are in a JIT context, so the comments > about using a platform specific LTO mechanism don't apply. > > Were you using this code to extract bitcode files from archives, or just to > link in an individual bitcode file? > Hi Daniel, I was using this code to

Looking at /tools/llvm-link/llvm-link.cpp may give you some ideas here. I havent looked at your specific use case, but llvm-link uses ParseIRFile to pull in a bitcode file and build a Module for it. You can then create a Composite using the Module * and call Linker::LinkModules(Composite.get(), NewModuleToLink.get()... to link a new Module to your Composite Module. -Chris On Feb 14, 2013, at

Hi, We're currently upgrading KLEE to work with LLVM >=3.3 and we've hit a problem. It seems r172749 removed support for linking a bitcode archive into a module. KLEE unfortunately depends on this to link in its runtime ( which amongst other things provides a C library [5] ). A first attempt at linking in a bitcode archive ourselves can be seen in [1]. This approach does not work

On Tue, Dec 17, 2013 at 10:31:31AM +0000, Daniel Liew wrote: > Hi, > > We're currently upgrading KLEE to work with LLVM >=3.3 and we've hit a problem. > > It seems r172749 removed support for linking a bitcode archive into a > module. KLEE unfortunately depends on this to link in its runtime ( > which amongst other things provides a C library [5] ). > > A

After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid. This commit fixes this by zero-ing the entire pipe_grid_info struct when declaring it, to avoid similar problems popping-up in the future. Signed-off-by: Hans de Goede <hdegoede at redhat.com> --- src/gallium/state_trackers/clover/core/kernel.cpp |

Hi, On 14-03-16 14:01, Samuel Pitoiset wrote: > > > On 03/14/2016 01:50 PM, Hans de Goede wrote: >> After pipe_grid_info.indirect was introduced, clover was not modified >> to set it causing it to pass uninitialized memory for it to launch_grid. >> >> This commit fixes this by zero-ing the entire pipe_grid_info struct when >> declaring it, to avoid similar

r172749 removed Linker/LinkArchives.cpp and Linker/LinkItems.cpp citing: This code is dead, and the "right" way to get this support is to use the platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM linker. Could someone please expand on what the "right way" is and these LTO mechanisms or where I can find further information? We used several

On 03/14/2016 02:29 PM, Samuel Pitoiset wrote: > > > On 03/14/2016 02:26 PM, Hans de Goede wrote: >> Hi, >> >> On 14-03-16 14:01, Samuel Pitoiset wrote: >>> >>> >>> On 03/14/2016 01:50 PM, Hans de Goede wrote: >>>> After pipe_grid_info.indirect was introduced, clover was not modified >>>> to set it causing it to pass

After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid. This commit fixes this by zero-ing the entire pipe_grid_info struct when declaring it, to avoid similar problems popping-up in the future. Cc: "11.2" <mesa-stable at lists.freedesktop.org> Signed-off-by: Hans de Goede <hdegoede at

After pipe_grid_info.indirect was introduced, clover was not modified to set it causing it to pass uninitialized memory for it to launch_grid. This commit fixes this by zero-ing the entire pipe_grid_info struct when declaring it, to avoid similar problems popping-up in the future. Cc: "11.2" <mesa-stable at lists.freedesktop.org> Signed-off-by: Hans de Goede <hdegoede at

Hi Chris, What functions were you using, and what features of them were you using? If you just need to link individual bit codes together, you can do it in exactly the same way that llvm-link does (using Linker::LinkModules). If you really need features like being able to pull objects out of archives, then you should use an LTO enabled linker (either the system linker on OS X, or gold + the gold

Hi Rafael and other LLVM devs, I'm currently upgrading a project that uses LLVM that links a bitcode archive (a C library) with a module. Originally we used Linker::LinkInFile() but that was removed by r172749. So I started looking for an alternative and I found Archive::findModulesDefiningSymbols() which looked very promising as it would allow me to very easily implement linking a bitcode

On 20 December 2013 05:39, Daniel Liew <daniel.liew at imperial.ac.uk> wrote: > Hi Rafael and other LLVM devs, > > I'm currently upgrading a project that uses LLVM that links a bitcode > archive (a C library) with a module. Originally we used > Linker::LinkInFile() but that was removed by r172749. So I started > looking for an alternative and I found >

Hi, I'm trying to compile UML with LLVM. However, LLVM-LD hangs whiile linking modules. It's consuming 99% of the CPU llvm-ld -v -r -o kernel/built-in.o kernel/sched.o kernel/fork.o kernel/exec_domain.o kernel/panic.o kernel/printk.o kernel/profile.o kernel/exit.o kernel/itimer.o kernel/time.o kernel/softirq.o kernel/resource.o kernel/sysctl.o kernel/capability.o kernel/ptrace.o

On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Extend the MEMORY file support to differentiate between global, local > and shared memory, as well as "input" memory. > > "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a > special memory type is added for this, since the actual storage of these > (e.g.

On 03/14/2016 01:50 PM, Hans de Goede wrote: > After pipe_grid_info.indirect was introduced, clover was not modified > to set it causing it to pass uninitialized memory for it to launch_grid. > > This commit fixes this by zero-ing the entire pipe_grid_info struct when > declaring it, to avoid similar problems popping-up in the future. > > Signed-off-by: Hans de Goede

On 03/14/2016 02:26 PM, Hans de Goede wrote: > Hi, > > On 14-03-16 14:01, Samuel Pitoiset wrote: >> >> >> On 03/14/2016 01:50 PM, Hans de Goede wrote: >>> After pipe_grid_info.indirect was introduced, clover was not modified >>> to set it causing it to pass uninitialized memory for it to launch_grid. >>> >>> This commit fixes this by

Samuel Pitoiset <samuel.pitoiset at gmail.com> writes: > On 03/14/2016 02:29 PM, Samuel Pitoiset wrote: >> >> >> On 03/14/2016 02:26 PM, Hans de Goede wrote: >>> Hi, >>> >>> On 14-03-16 14:01, Samuel Pitoiset wrote: >>>> >>>> >>>> On 03/14/2016 01:50 PM, Hans de Goede wrote: >>>>> After

Hi, Going ahead, the llvm-ld seems to segfault (build on Linux with llvm-ld v3.0svn build): make[2]: Entering directory `/root/code/vmkit/mmtk/mmtk-j3' llvm[2]: Building Debug+Asserts Bytecode Module MMTKRuntime.bc 0 llvm-ld 0x0884c66e 1 llvm-ld 0x0884c3fb 2 0xb7891400 __kernel_sigreturn + 0 3 llvm-ld 0x083be9e9 llvm::isa_impl<llvm::Constant,