search for: linkinfiles

Hi Daniel, In r172749 you removed the Linker::LinkInFiles() function and mentioned in the commit message that users of this function should migrate to "platform-specific linker-integrated LTO mechanisms, or the forthcoming LLVM linker." I'm trying to update this code: http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/state_trackers/clo...

...O 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 removed the Linker::LinkInFiles() function and mentioned > in the commit message that users of this function should migrate to > "platform-specific linker-integrated LTO mechanisms, or the forthcoming > LLVM linker." > > I'm trying to update this code: > > http://cgit.freedesktop.org/mesa/mesa/t...

...nd OpenCL C kernel to bitcode and then link it with an OpenCL C builtin library which was also a bitcode file. -Tom > > > On Wed, Feb 13, 2013 at 12:24 PM, Tom Stellard <tom at stellard.net> wrote: > > > Hi Daniel, > > > > In r172749 you removed the Linker::LinkInFiles() function and mentioned > > in the commit message that users of this function should migrate to > > "platform-specific linker-integrated LTO mechanisms, or the forthcoming > > LLVM linker." > > > > I'm trying to update this code: > > > > http...

...an OpenCL C > builtin library which was also a bitcode file. > > -Tom > > >> >> >> On Wed, Feb 13, 2013 at 12:24 PM, Tom Stellard <tom at stellard.net> wrote: >> >>> Hi Daniel, >>> >>> In r172749 you removed the Linker::LinkInFiles() function and mentioned >>> in the commit message that users of this function should migrate to >>> "platform-specific linker-integrated LTO mechanisms, or the forthcoming >>> LLVM linker." >>> >>> I'm trying to update this code: >>...

...0000000495da7 in ?? () #61 0x0000000000495be5 in ?? () #62 0x0000000000495da7 in ?? () #63 0x0000000000495be5 in ?? () #64 0x000000000049609a in ?? () #65 0x000000000049ab6f in llvm::Linker::LinkModules () #66 0x0000000000491643 in llvm::Linker::LinkInFile () #67 0x0000000000491e57 in llvm::Linker::LinkInFiles () #68 0x00000000004727df in main () any ideas what could be wrong here? thanks.

...3dce74 llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::string*) + 64 14 llvm-ld 0x083d949a llvm::Linker::LinkInModule(llvm::Module*, std::string*) + 46 15 llvm-ld 0x083d926c llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&) + 1524 16 llvm-ld 0x083d943d llvm::Linker::LinkInFiles(std::vector<llvm::sys::Path, std::allocator<llvm::sys::Path> > const&) + 67 17 llvm-ld 0x083ad740 main + 1329 18 libc.so.6 0xb75d3cc6 __libc_start_main + 230 19 llvm-ld 0x083a67c1 Stack dump: 0. Program arguments: /root/code/llvm/Debug+Asserts/bin/llvm-ld -r -o /root/code/vmk...

...in "unioning" types. What I'm still uncomfortable with is, I don't understand under what conditions the system should union two opaque types with the same name and def. The above method BitcodeReader::ParseTypeTableBody, never seems to do this, and therefore my reading of Linker::LinkInFiles won't do it either for say two bitcode files accessing/realizing the same named StructType. On the other hand when hand coding two modules using in memory IR, I have a choice in either checking with NamedStructTypes to to force two equivalently named struct types to resolve to the same struct t...

...Reader.cpp:2102 #16 0x0000000000de1b76 in llvm::Linker::LoadObject (this=0x7fffffffdc60, FN=@0x1d6a330) at Linker.cpp:106 #17 0x0000000000dd03eb in llvm::Linker::LinkInFile (this=0x7fffffffdc60, File=@0x1d6a330, is_native=@0x7fffffffd64b) at LinkItems.cpp:196 #18 0x0000000000dd07ea in llvm::Linker::LinkInFiles (this=0x7fffffffdc60, Files=std::vector of length 1, capacity 1 = {...}) at LinkItems.cpp:235 #19 0x0000000000b8a904 in main (argc=2, argv=0x7fffffffe098, env=0x7fffffffe0b0) at main.cpp:209 If I do _not_ include the following line at the beginning of my program llvm::llvm_start_multithr...

...Modules(llvm::Module*, llvm::Module*, > std::string*) + 64 > 14 llvm-ld 0x083d949a llvm::Linker::LinkInModule(llvm::Module*, std::string*) + 46 > 15 llvm-ld 0x083d926c llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&) > + 1524 > 16 llvm-ld 0x083d943d llvm::Linker::LinkInFiles(std::vector<llvm::sys::Path, > std::allocator<llvm::sys::Path> > const&) + 67 > 17 llvm-ld 0x083ad740 main + 1329 > 18 libc.so.6 0xb75d3cc6 __libc_start_main + 230 > 19 llvm-ld 0x083a67c1 > Stack dump: > 0. Program arguments: /root/code/llvm/Debug+Asserts/bi...

...000000000495be5 in ?? () > #62 0x0000000000495da7 in ?? () > #63 0x0000000000495be5 in ?? () > #64 0x000000000049609a in ?? () > #65 0x000000000049ab6f in llvm::Linker::LinkModules () > #66 0x0000000000491643 in llvm::Linker::LinkInFile () > #67 0x0000000000491e57 in llvm::Linker::LinkInFiles () > #68 0x00000000004727df in main () > > any ideas what could be wrong here? thanks. >

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

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

...t; > std::string*) + 64 > > 14 llvm-ld 0x083d949a llvm::Linker::LinkInModule(llvm::Module*, > std::string*) + 46 > > 15 llvm-ld 0x083d926c llvm::Linker::LinkInFile(llvm::sys::Path const&, > bool&) > > + 1524 > > 16 llvm-ld 0x083d943d > llvm::Linker::LinkInFiles(std::vector<llvm::sys::Path, > > std::allocator<llvm::sys::Path> > const&) + 67 > > 17 llvm-ld 0x083ad740 main + 1329 > > 18 libc.so.6 0xb75d3cc6 __libc_start_main + 230 > > 19 llvm-ld 0x083a67c1 > > Stack dump: > > 0. Program arguments: /r...

...ng" types. What I'm still uncomfortable with is, I > don't understand under what conditions the system should union two opaque types with the > same name and def. The above method BitcodeReader::ParseTypeTableBody, never seems to do > this, and therefore my reading of Linker::LinkInFiles won't do it either for say two bitcode files > accessing/realizing the same named StructType. The idea is that the linker does this when there is linkage that implies that two types should be unioned. For example: %A = type opaque @G = external global %A* ...and... %A = type { i32 } @G =...

...fbfcd50, FN=@0x101801a28) at /Users/talin/Projects/llvm/lib/Linker/Linker.cpp:107 #12 0x000000010006494e in llvm::Linker::LinkInFile (this=0x7fff5fbfcd50, File=@0x101801a28, is_native=@0x7fff5fbfcb7f) at /Users/talin/Projects/llvm/lib/Linker/LinkItems.cpp:199 #13 0x0000000100064c5e in llvm::Linker::LinkInFiles (this=0x7fff5fbfcd50, Files=@0x7fff5fbfce30) at /Users/talin/Projects/llvm/lib/Linker/LinkItems.cpp:238 #14 0x0000000100007c1f in main (argc=130, argv=0x7fff5fbfd1f0, envp=0x7fff5fbfd608) at /Users/talin/Projects/llvm/tools/llvm-ld/llvm-ld.cpp:582 I'll get you a reproducible test case in the n...

...0x083d949a llvm::Linker::LinkInModule(llvm::Module*, >>> std::string*) + 46 >>> > 15 llvm-ld 0x083d926c llvm::Linker::LinkInFile(llvm::sys::Path >>> const&, bool&) >>> > + 1524 >>> > 16 llvm-ld 0x083d943d >>> llvm::Linker::LinkInFiles(std::vector<llvm::sys::Path, >>> > std::allocator<llvm::sys::Path> > const&) + 67 >>> > 17 llvm-ld 0x083ad740 main + 1329 >>> > 18 libc.so.6 0xb75d3cc6 __libc_start_main + 230 >>> > 19 llvm-ld 0x083a67c1 >>> > Stack dum...

Sanjiv Gupta wrote: > Nick Lewycky wrote: >> Sanjiv.Gupta at microchip.com wrote: >>> >>> >>> A common followup question is "but how do I link native libraries into >>> my .bc file". You don't. A .bc file is llvm ir, you can't put a native >>> binary library into a .bc (barring sticking it in as a string, etc). >>>

...gt;> > 14 llvm-ld 0x083d949a llvm::Linker::LinkInModule(llvm::Module*, >> std::string*) + 46 >> > 15 llvm-ld 0x083d926c llvm::Linker::LinkInFile(llvm::sys::Path const&, >> bool&) >> > + 1524 >> > 16 llvm-ld 0x083d943d >> llvm::Linker::LinkInFiles(std::vector<llvm::sys::Path, >> > std::allocator<llvm::sys::Path> > const&) + 67 >> > 17 llvm-ld 0x083ad740 main + 1329 >> > 18 libc.so.6 0xb75d3cc6 __libc_start_main + 230 >> > 19 llvm-ld 0x083a67c1 >> > Stack dump: >> > 0....

Several people on this list have reported issues with the linker regarding a named StructType instance with the same name in two different modules being resolved into two StructTypes with different names due to StructType:: setName(…) collision behavior. Looking at BitcodeReader::ParseTypeTableBody(…), I don't see use of LLVMContextImpl::NamedStructTypes or of Module::getTypeByName(…). Nor do

...dule*, >>>>> std::string*) + 46 >>>>> > 15 llvm-ld 0x083d926c llvm::Linker::LinkInFile(llvm::sys::Path >>>>> const&, bool&) >>>>> > + 1524 >>>>> > 16 llvm-ld 0x083d943d >>>>> llvm::Linker::LinkInFiles(std::vector<llvm::sys::Path, >>>>> > std::allocator<llvm::sys::Path> > const&) + 67 >>>>> > 17 llvm-ld 0x083ad740 main + 1329 >>>>> > 18 libc.so.6 0xb75d3cc6 __libc_start_main + 230 >>>>> > 19 llvm-ld 0x083a...