similar to: [LLVMdev] [LLVM] What has happened to LLVM bitcode archive support?

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

Hi Rafael, On 20 Dec 2013, at 14:30, Rafael Espíndola wrote: > 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

>> Therefore LLVM is still supporting runtime libraries that consist of llvm >> bitcode files (even if the format is now different) > > runtime? It is still possible to build .a files if that is what you men. Sorry I haven't explained very clearly. The tool that I work on is an interpreter of LLVM IR and when the tool runs, it links in an archive of bitcode modules into the

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

> Excuse me for the diversion but, is that interpreter of LLVM IR available > somewhere? Details on how it works, performance, etc? I'd be interested Yes it is available. The tool (KLEE [1]) is actually a lot more than an interpreter (although it can be used as one). KLEE allows you to mark certain variables (e.g. program inputs) as "symbolic". What this means is that the

Hi, Encounter a compilation issue related to c++. Software versions: - gcc 4.7.4 - llvm git commit 98a1ca117e6743dd7f2d505443a96f591d083eab Build log: Scanning dependencies of target LLVMLTO [ 53%] Building CXX object lib/LTO/CMakeFiles/LLVMLTO.dir/Caching.cpp.o /tmp/pkgs/llvm/lib/LTO/Caching.cpp: In lambda function: /tmp/pkgs/llvm/lib/LTO/Caching.cpp:74:7: error: looser throw specifier for

> I would suggest for now building the archive with gnu ar and the > plugin, that way you have an index and don't need to read all members. Thanks for the suggestion.I'll check out [1]. It would be definitely be faster using LLVMGold.so with ar but to be honest I'd rather take a small performance hit but make life much easier for our users at the moment because the build process

On Mon, Dec 3, 2012 at 2:08 PM, Relph, Richard <Richard.Relph at amd.com> wrote: > On Nov 21, 2012, at 4:28 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > >> On Nov 21, 2012, at 12:09 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: >> >>> Note that I plan to remove llvm/Bitcode/Archive once Object/Archive is >>>

> > $ llvm-gcc --emit-llvm -c a.c -o a.o > > $ llvm-gcc -c main.c -o main.o > > $ llvm-gcc a.o main.o -o main > > a.o: file not recognized: File format not recognized > > collect2: ld returned 1 exit status > > > > Okay, that did not really work :-/ > > This document describes interface between llvm and linker. You need > system linker that

When having a project that's partially bitcode and partially native code, should lld allow linking a native .o to a bitcode .o? specifically in my case, I've got an stdcall function in bitcode, called by native code, but it can't find the symbol (bitcode has it unmangled, native code with _ and @20)

Mixing native and bitcode files should just work, and that happens all the time, as most programs need at least crt.o (which is a precompiled native object file containing startup code). Could you elaborate the issue a bit? It might be a bug in lld. On Fri, Mar 30, 2018 at 3:11 AM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Fri, Mar 30, 2018, at 11:23, Carlo Kok

The problem is a bitcode implementation that has a stdcall function that's used from native code. 1 side has _elements_exception_handler, compiled that would be __elements_exception_handler at 20 due to stdcall. The native bit has the mangled name and the linker can't find it as the bitcode indexes have it without mangling. I'll try to prepare a testcase when I get back in the office.

Clang may be avoiding this problem because it will always emit "\01__elements_exception_handler at 20" as the function name. It probably does that for precisely this reason. On Fri, Mar 30, 2018 at 11:55 AM Carlo Kok via llvm-dev < llvm-dev at lists.llvm.org> wrote: > The problem is a bitcode implementation that has a stdcall function that's > used from native code. 1

On Fri, Mar 30, 2018, at 11:23, Carlo Kok via llvm-dev wrote: > When having a project that's partially bitcode and partially native code, should lld allow linking a native .o to a bitcode .o? > > specifically in my case, I've got an stdcall function in bitcode, called by native code, but it can't find the symbol (bitcode has it > unmangled, native code with _ and @20)

Hi, In the presence of both a normal archive (e.g., libclangLex.a) and a bitcode archive (e.g., libclangLex.bca), how to force the llvm linker (llvm-ld) to link to the bitcode archive instead of the normal archive? Currently, I achieved the goal by removing the normal archive, but I am wondering if there is a better to do so? Best, Xiaolong

Hi, We would like to add a version number to the bitcode wrapper. This feature would allow easier identification of what compiler produced the bitcode so that known incompatibilities with LTO compilation could be detected. Roughly speaking, this version number would consist of the major, minor and optionally the patch version of the compiler used to produce the bitcode. The version information

On Nov 21, 2012, at 4:28 PM, "Relph, Richard" <Richard.Relph at amd.com> wrote: > On Nov 21, 2012, at 12:09 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > >> Note that I plan to remove llvm/Bitcode/Archive once Object/Archive is >> capable of replacing it. The llvm tools that don't write archives >> files have already been switched over

On Tue, Dec 13, 2011 at 9:27 PM, Rafael Ávila de Espíndola < rafael.espindola at gmail.com> wrote: > > > $ llc bar.bc -filetype=obj -o bar.o > > $ clang -shared -o bar.so bar.o > > $ clang -use-gold-plugin foo.o bar.so -o t > > > > Is that correct? In particular, "lld t" should show a dependency on > bar. > > Any