<meta http-equiv="content-type" content="text/html; charset=utf-8"><span class="Apple-style-span" style="border-collapse: collapse; color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 10px; ">Hmm.. I didn't explain the problem completely last time. I am creating a drop-in replacement for gcc and gfortran that runs an additional pass on the bitcode before generating the native binary. Here's whats happening: If the source code compilation process builds a static library (.a archive file), I need a means to link the `.a' file statically into the application. So if the original statement was:<div>
<br></div><div>gfortran file.o -L somedir -lmylib -o file</div><div><br></div><div>then my modified compilation process would have to deal with file.o and libmylib.a to generate the binary `file'. Now, all files essentially contain bitcode (file.o and object files inside libmylib.a). So the pseudo-code would look like:</div>
<div><br></div><div>-- QUOTE --</div><div><br></div><div>For all input files passed to compiler:</div><div> If extension is .o:</div><div> Use llc to generate .s file</div><div> Add this filename to some collection</div>
<div> Else if extension is .a:</div><div> Extract contents of this archive</div><div> Use llc on each file to generate .s file</div><div> Add each filename to the collection</div><div> End if</div>
<div>End for</div><div><br></div><div>Retrieve all `.s' filenames and pass them all to gcc or gfortran</div><div><br></div><div>-- UNQUOTE --</div><div><br></div><div>But the part that deals with `.a' files is a bit ugly. llvm-ld handles the archive (.a) files without any manual extraction but I fear that because llvm-ld is not a full-featured linker, I might run into a wall because of incompatible options between gfortran/gcc and llvm-ld.</div>
<div><br></div><div>Ashay</div><div><br></div></span><br><div class="gmail_quote">On Mon, Sep 12, 2011 at 3:38 PM, Dmitry N. Mikushin <span dir="ltr"><<a href="mailto:maemarcus@gmail.com">maemarcus@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Sorry, at what step do you need archive? llc emits binary, it does not<br>
perform any linking, thus it does not need anything except the input<br>
bytecode file. Then during linking you can link whatever archives of<br>
binaries you want.<br>
<br>
2011/9/13 Ashay Rane <<a href="mailto:ashay.rane@tacc.utexas.edu">ashay.rane@tacc.utexas.edu</a>>:<br>
<div><div></div><div class="h5">> Thats correct. But using llc becomes a problem when I have archives (.a<br>
> files). I could, in theory, extract its contents to a tempdir and then use<br>
> llc and link but just wondering if there is a more elegant solution.<br>
> Ashay<br>
><br>
> On Mon, Sep 12, 2011 at 3:00 PM, Dmitry N. Mikushin <<a href="mailto:maemarcus@gmail.com">maemarcus@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Ashay,<br>
>><br>
>> If I understand correctly, in hw.o you would have llvm bytecode, while<br>
>> linker expects regular object binary. Probably first you need to emit<br>
>> asm out of bytecode using llc?<br>
>><br>
>> - D.<br>
>><br>
>> 2011/9/12 Ashay Rane <<a href="mailto:ashay.rane@tacc.utexas.edu">ashay.rane@tacc.utexas.edu</a>>:<br>
>> > Hello,<br>
>> > Sorry for the late reply. Using dragonegg worked well, thanks all!<br>
>> > Just as a note... I had to use llvm-ld during the link step because<br>
>> > gfortran<br>
>> > could not link bitcode. Here's an example of the error shown when using<br>
>> > gfortran instead of llvm-ld:<br>
>> > $ ${GCC_4_5_0}/bin/gfortran hw.f -c<br>
>> > -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so -o hw.o -flto -emit-llvm -S<br>
>> > $ ${LLVM_2_9}/bin/opt -mem2reg hw.o -o hw.o<br>
>> > $ ${GCC_4_5_0}/bin/gfortran<br>
>> ><br>
>> > -fplugin=${DRAGONEGG_PLUGIN}/dragonegg.so ${GCC_4_5_0}/lib64/libgfortran.a<br>
>> > hw.o -o hw<br>
>> > hw.o: file not recognized: File format not recognized<br>
>> > collect2: ld returned 1 exit status<br>
>> > $ file hw.o<br>
>> > hw.o: data<br>
>> > Instead, using llvm-ld:<br>
>> > $ ${LLVM_2_9}/bin/llvm-ld -native hw.o -o hw<br>
>> > ${GCC_4_5_0}/lib64/libgfortran.a -lm<br>
>> > llvm-gcc had the gold plugin. I wonder if there is any equivalent of<br>
>> > that<br>
>> > for dragonegg to be able to compile bitcode and native object code in a<br>
>> > transparent manner.<br>
>> > Thanks again!<br>
>> > Ashay<br>
>> ><br>
>> > On Wed, Aug 31, 2011 at 4:29 PM, Anton Korobeynikov<br>
>> > <<a href="mailto:anton@korobeynikov.info">anton@korobeynikov.info</a>> wrote:<br>
>> >><br>
>> >> Hello<br>
>> >><br>
>> >> > I am not very familiar with Fortran programs. I saw a few programs<br>
>> >> > that<br>
>> >> > had<br>
>> >> > a "MAIN" subroutine defined, some others that did not. Am I missing<br>
>> >> > something while compiling the code? Is there a different way to<br>
>> >> > compile<br>
>> >> > bitcode (from Fortran programs) to a native binary?<br>
>> >> For Fortran MAIN is indeed something similar to C main, but not<br>
>> >> exactly the same.<br>
>> >> You have to link the runtime library (libgfortran.a) in order to get<br>
>> >> "proper" main, mak sure all stuff is initialized properly, etc.<br>
>> >><br>
>> >> --<br>
>> >> With best regards, Anton Korobeynikov<br>
>> >> Faculty of Mathematics and Mechanics, Saint Petersburg State University<br>
>> ><br>
>> ><br>
>> > _______________________________________________<br>
>> > LLVM Developers mailing list<br>
>> > <a href="mailto:LLVMdev@cs.uiuc.edu">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a><br>
>> > <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
>> ><br>
>> ><br>
><br>
><br>
</div></div></blockquote></div><br>