[LLVMdev] Compiling zlib to static bytecode archive

[Maarten ter Huurne]

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
>
> Where llvm-collect2 is just collect2 that dlopen's liblto to do the
> optimization work. This makes it work much more naturally than adding
> a whole new set of steps.  Depending on llvm-ld will never get you to
> a world where LTO is transparent, because llvm-ld doesn't support a
> lot of options and features that native linkers do.

So the llvm-collect2 will combine the functionality of the original collect2 
and of llvm-ld?

When it executes, it would take the following steps:
1. for each input, determine whether it is in bytecode or native format
2. if there are no bytecode inputs, go to step 6
3. link the bytecode inputs and optimize the resulting bytecode, using liblto
4. if bytecode output was requested, we are done
5. generate native object in a temporary file
6. perform the init/exit fixups that the original collect2 does
7. invoke system linker to link the generated native object (if any) and the 
input native objects (if any)

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 processing and then runs the 
original, unmodified collect2:
  llvm-gcc -> llvm-collect2(liblto) -> collect2 -> ld

Bye,
		Maarten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070926/0f16aebb/attachment.sig>