similar to: [LLVMdev] Dropped support for IR-level extended linking support (archives, etc.)

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

On 23 July 2012 17:03, Chris Cadwallader <ccadwallader at arxan.com> wrote: > On Darwin, if -march is armv7 clang's driver will assume you want thumb2 unless you also give it -mno-thumb but that is irrelevant with mcpu=cortex-m3. I think that Thumb2 should be the default for v7 on any system, not just Darwin. Maybe some ARM folk can comment on this... -- cheers, --renato

On Mon, Jul 23, 2012 at 8:14 PM, Renato Golin <rengolin at systemcall.org> wrote: > On 23 July 2012 17:03, Chris Cadwallader <ccadwallader at arxan.com> wrote: >> On Darwin, if -march is armv7 clang's driver will assume you want thumb2 unless you also give it -mno-thumb but that is irrelevant with mcpu=cortex-m3. > > I think that Thumb2 should be the default for v7

hi, i just try to build llvm-3.0 (stable) on linux ppc32 (CRUX PPC 2.7) with gcc-4.5.3, binutils-2.21.1, glibc-2.12.2 . As this suggestion: http://llvm.org/bugs/show_bug.cgi?id=10969 I applied a patch like this one: --- llvm-3.0.src/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h 2011-07-26 01:24:55.000000000 +0200 +++ llvm-3.0.src/lib/Target/PowerPC/MCTargetDesc/PPCMCTargetDesc.h

On Darwin, if -march is armv7 clang's driver will assume you want thumb2 unless you also give it -mno-thumb but that is irrelevant with mcpu=cortex-m3. I agree its a mess. -Chris On Jul 22, 2012, at 4:37 PM, Renato Golin wrote: > On 22 July 2012 20:42, Anton Korobeynikov <anton at korobeynikov.info> wrote: >>> Any suggestions? >> Try to specify CPU explicitly. >

Teja, Your mention of .s being bytecode confuses me, but if you're asking how to lower a bitcode (.bc) or IR file (.ll) to assembly (.s) than llc is the tool you are looking for. llc -O2 path/to/bitcode/input.bc -o output.s -Chris On Mar 7, 2013, at 10:39 PM, teja tamboli wrote: > Hello, > > I am looking for tool to convert file from either (.s) bytecode or (.bc) bitcode to

Hello, I am looking for tool to convert file from either (.s) bytecode or (.bc) bitcode to .asm file. Basically assembly instruction file for my x86 backend. I think so we can use llvm-objdump. However I am not able to figure out its exact options. Could you please tell me how to do that? -- Thanks, Teja -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

On 22 July 2012 20:42, Anton Korobeynikov <anton at korobeynikov.info> wrote: >> Any suggestions? > Try to specify CPU explicitly. He shouldn't have to, but that might help. Maybe setting -march? This is a big mess... I thought that v7 always assumed Thumb2 for the thumb flag, and v7M should always assume Cortex-M3 CPU if none provided. It's funny that James had a great

Nico, There is a third place that '#undef PPC' is needed (at the top of PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in your CPPFLAGS. I'll try to get this fixed in trunk shortly. -Hal On Fri, 2011-12-02 at 12:30 +0100, acrux_it at libero.it wrote: > hi, i just try to build llvm-3.0 (stable) on linux ppc32 (CRUX PPC 2.7) with > gcc-4.5.3, binutils-2.21.1,

On Fri, 2011-12-02 at 06:58 -0600, Hal Finkel wrote: > Nico, > > There is a third place that '#undef PPC' is needed (at the top of > PPCFixupKinds.h). Alternatively, you can run configure with -UPPC in > your CPPFLAGS. I'll try to get this fixed in trunk shortly. I just tested this, and I was wrong: passing -UPPC to configure in CPPFLAGS does not work for some reason.

I am just getting started with llvm. Here's code I am trying to compile: #include <stdio.h>#include "llvm/IR/LLVMContext.h"#include "llvm/IR/Module.h"#include "llvm/IR/IRBuilder.h" int main(){ llvm::LLVMContext& context = llvm::getGlobalContext(); llvm::Module* module = new llvm::Module("top", context); llvm::IRBuilder<>

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

Hi, Reid Spencer wrote: > Call getBytecodeModuleProvider (see Reader.h). The problem is that one needs to provide the filename of the original module as the argument of getBytecodeModuleProvider, whereas this is unknown (it's exactly what we're trying to find out). But, by looking where this method is called in the original bytecode loading process, I figured out a way to set the

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

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

Here is the bulk of the sanitizing. My residual doubts center around the question whether we still do/want to support (un)compressed *byte*code in 2.0/2.1. I need a definitive word on this to proceed. My understanding is that bytecode is already gone, but there are still some functions/enums that really deal with *byte*code (instead of *bit*code). I did not touch those areas, so the attached

Hi Bram, On Sun, 2006-09-24 at 22:58 +0200, Bram Adams wrote: > Hi, > > During link-time optimization using llvm-ld, I occasionally need to > find the name/ID of the original module/bytecode file a Function > belonged to. In order to do this I added a nameOfPreviousModule- > attribute to Function and some getters/setters (see attached patch). > However, I can't

Hi llvmdev! In our project (Windows, Visual Studio compiler) we've got some frontend which generates LLVM IR. Now I'm observing strange *llvm_shutdown* behavior. If I called it when I was done using the LLVM APIs I saw that destructors of static objects created new ManagedStatic objects, which was never freed. Then I tried to use static global llvm_shutdown_obj to cause destruction