similar to: [LLVMdev] Compiling zlib to static bytecode archive

On Sep 21, 2007, at 9:42 AM, Maarten ter Huurne wrote: > However, it is not possible to let the zlib Makefile issue that > command > without patching the Makefile, because the fragment that does the > linking is > hardcoded to use the compiler command for linking: > > example$(EXE): example.o $(LIBS) > $(CC) $(CFLAGS) -o $@ example.o $(LDFLAGS) Right,

On Friday 21 September 2007, Chris Lattner wrote: > On Sep 21, 2007, at 9:42 AM, Maarten ter Huurne wrote: > > However, it is not possible to let the zlib Makefile issue that > > command > > without patching the Makefile, because the fragment that does the > > linking is > > hardcoded to use the compiler command for linking: > > > > example$(EXE):

On Sep 23, 2007, at 3:27 AM, Maarten ter Huurne wrote: > On Friday 21 September 2007, Chris Lattner wrote: >> On Sep 21, 2007, at 9:42 AM, Maarten ter Huurne wrote: >>> However, it is not possible to let the zlib Makefile issue that >>> command >>> without patching the Makefile, because the fragment that does the >>> linking is >>> hardcoded

On Wednesday 26 September 2007, Chris Lattner wrote: > > llvm-gcc calling llvm-ld: > > llvm-gcc -> llvm-ld -> gcc -> collect2 -> ld > > > > enhance collect2: > > llvm-gcc -> llvm-collect2 -> llvm-ld -> gcc -> collect2 -> ld > > I'd rather enhance collect2 like this: > > llvm-gcc -> llvm-collect2(liblto) -> ld >

On Wednesday 26 September 2007, Chris Lattner wrote: > > Assuming those steps are correct, step 6 and 7 could be implemented > > by using > > the original collect2 and adding the generated native object to the > > list of > > files to link. In other words, llvm-collect2 could be a separate > > process, > > which is called instead of collect2, does some

On Sep 25, 2007, at 6:12 PM, Maarten ter Huurne wrote: > On Wednesday 26 September 2007, Chris Lattner wrote: > >>> llvm-gcc calling llvm-ld: >>> llvm-gcc -> llvm-ld -> gcc -> collect2 -> ld >>> >>> enhance collect2: >>> llvm-gcc -> llvm-collect2 -> llvm-ld -> gcc -> collect2 -> ld >> >> I'd rather

On Wed, 26 Sep 2007, Maarten ter Huurne wrote: >>> process, >>> which is called instead of collect2, does some processing and then >>> runs the >>> original, unmodified collect2: >>> llvm-gcc -> llvm-collect2(liblto) -> collect2 -> ld >> >> Sure, this would also work. Is there any reason not to merge them >> together? >

On Thursday 27 September 2007, Chris Lattner wrote: > >> Sure, this would also work. Is there any reason not to merge them > >> together? > > > > Ease of maintenance, mainly. Having it in a separate file makes it > > easier to migrate the code to new GCC releases. Also, collect2.c is > > already 2658 lines, which is more than I typically like to have in

Hello, Maarten > As far as I can see, collect2.c does not read the object files though: it > only runs "nm" on them, which is not what we need to determine which files > are bitcode files. This can be identified via LLVM's sys::IdentifyFileType() > One thing I'm wondering is how to merge the C code of collect2 with the C++ > code that uses liblto: > -

I am trying to obtain native code from the bytecode by using commands: % llc hello.bc -o hello.s % gcc hello.s -o hello.native This is working for a simple program( a single source file) but when I try to run it on grep utility (grep.bc) , it gives me the following error: $ llc grep.bc -o grep.s $ gcc grep.s -o grep.native /tmp/ccY3oNAA.o(.text+0x2f2f): In function `main': :

Chandler/Domagoj, On Sun, 2006-12-10 at 10:53 -0500, Chandler Carruth wrote: > Unless I'm missing something, the problem lies directly with the fact > that you are trying to do a link-stage operation with the GCC > frontend. GCC, by default, probably runs "ld" or another system > linker, which grabs the executable from binutils. This linker hasn't > been modified

Reid Spencer wrote: > Chandler/Domagoj, > > On Sun, 2006-12-10 at 10:53 -0500, Chandler Carruth wrote: > >>Unless I'm missing something, the problem lies directly with the fact >>that you are trying to do a link-stage operation with the GCC >>frontend. GCC, by default, probably runs "ld" or another system >>linker, which grabs the executable from

I'm attempting to build a native build of clang from the 3.2 source distribution tarballs, but I ran into this build error that's got me really puzzled. My platform is Linux - 32-bit Ubuntu (12.04) running on a PC. Here's the (abbreviated) output from make: *************************************** ... make[3]: Entering directory

I'm continuing this here in llvm-dev since the thread was started here, but, in hindsight, it may have been better in cfe-dev, because the problem seems to be related to clang. I turned on "verbose" mode in make (VERBOSE=1 TOOL_VERBOSE=1) and found that it is clang, not gcc, that is being used at this point in the make. Based on the command issued (particularly with the --sysroot

I am trying to disassemble some bytecode using llvm-dis: llvm-dis -f -o llvmtest/sliceme2.cbc.ll llvmtest/sliceme2.cbc However, I am getting the following error. llvm-dis: Invalid bytecode signature: 464C457F (Vers=0, Pos=4) How do I go about figuring out what the problem is? llvmtest/sliceme2.cbc is newly compiled using the same version of llvm-gcc as llvm-dis. -- Ryan M. Lefever

Hi: For some reason, I changed the files /ByteCode/Writer/Writer.cpp and /ByteCode/Reader/Reader.cpp and I introduced an new version number 6. Now I replaced these two changed files with the original ones that are version 5. And I rebuild the llvm compiler. What make me mad is that the bytecode produced now is still version 6! Of course the reader cannot recognize it because the current reader

I am trying to use LLVM as a source to source C compiler. I use llvm-gcc to convert file.c->file.bc. Then I use opt to run my own compiler passes to convert file.bc->file.opt.bc. Then I use llc to convert file.opt.bc->file.opt.c. Now, I want to use normal gcc to compile file.opt.c into an executable. However, I'm getting the following errors: test.opt.c:89: warning:

Hi, I'm changing bytecode format a little bit, i.e. for 2 operands Instructions, the original is like this: 01-00:Opcode type 07-02:Opcode 15-08: Instruction type 23-16: Operand#1 31-24: Operand#2 My change is like this: 01-00:Opcode type 07-02:Opcode 15-08: Instruction type 16: myflag1 17: myflag2 24-18: Operand#1 31-25: Operand#2 I do

Is there any documentation of the llvm bytecode format? I looked around the website but didn't see any; did I miss some obvious document? Thanks a bunch. --Grant

Hi Ryan, On Fri, 2006-12-01 at 18:06 -0600, Ryan M. Lefever wrote: > I am trying to disassemble some bytecode using llvm-dis: > llvm-dis -f -o llvmtest/sliceme2.cbc.ll llvmtest/sliceme2.cbc > > However, I am getting the following error. > > llvm-dis: Invalid bytecode signature: 464C457F (Vers=0, Pos=4) The problem is most likely that sliceme2.cbc is *not* bytecode. Open the