search for: linkinfile

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/cl...

...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/...

...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: > > > > htt...

...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: >&gt...

...da7 in ?? () #59 0x0000000000495be5 in ?? () #60 0x0000000000495da7 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.

...lobalAlias::getAliasee() + 37 11 llvm-ld 0x083dc3c6 12 llvm-ld 0x083dcdb5 13 llvm-ld 0x083dce74 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 Sta...

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

...er.cpp:2084 #15 0x0000000000df84e3 in llvm::ParseBitcodeFile (Buffer=0x1d754c0, Context=@0x7fffffffdd90, ErrMsg=0x7fffffffd3f0) at BitcodeReader.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=0...

...> 11 llvm-ld 0x083dc3c6 > 12 llvm-ld 0x083dcdb5 > 13 llvm-ld 0x083dce74 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 &g...

...in ?? () > #60 0x0000000000495da7 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. >

...(the set of undefined symbols does not change ). Does that apply here? I guess the answer depends on the behaviour of Linker:: LinkModules(). If it does that would make [1] incorrect as it only links in the archive's modules once. * Why is the approach so slow compared to using the old Linker::linkInFile() API in prior LLVM versions? What ever the answers are to the above, the approach in [1] isn't right. So what is the right way to programmatically link in LLVM bitcode archives into a bitcode module? I noted that the r172749 commit says... ``` the "right" way to get this support i...

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 archive with a module efficiently (i.e. only call Linker::LinkModules() on the rel...

...gt; 12 llvm-ld 0x083dcdb5 > > 13 llvm-ld 0x083dce74 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 0x...

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

...text=@0x101600290, ErrMsg=0x7fff5fbfc8f0) at /Users/talin/Projects/llvm/lib/Bitcode/Reader/BitcodeReader.cpp:2792 #11 0x000000010006cf52 in llvm::Linker::LoadObject (this=0x7fff5fbfcd50, 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 0x0000000100...

...llvm-ld 0x083dce74 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...

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). >>>

...db5 >> > 13 llvm-ld 0x083dce74 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 &...

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

...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&am...