[PATCH][LTO][RFC] AR archive support for LTO

Rafael Espindola espindola@google.com
Mon Nov 2 17:42:00 GMT 2009


> Sure, the size shouldn't even be needed, just use elf_rand to seek
> to the archive member.

Sure.

> It would pass the full archive to the link if there is any file w/o
> LTO data in the archive.

That is not the correct behavior even for archives with only IL in
them. If an archive has a.o and b.o but only b.o is used, a.o should
not be passed to lto1.

>> Do consider patching GNU ld or moving to gold instead :-)
>
> Heh.  I'm not really into the linker code(s).

I am not really into BFD code, but I might be tempted to take a look
to keep the lto1 interface simpler :-)

> Thanks - try to keep it simple and omit the size.
>
> Here's my current patch btw, avoiding the elfutils bug workaround.

Attached is a work in progress that merges your patch with the
necessary changes to the plugin. With this we can do

 ./gcc/xgcc   -O2 -flto -B ./gcc/ test.o test2.a -o t
-fuse-linker-plugin -B ./lto-plugin/.libs/

And lto1 correctly sees all the necessary IL files and no temporary .o
is created :-)

Things I am not 100% happy with in the patch:

*) The hack in gcc.c. What is the correct solution? Making gcc.c
ignore filenames with a @ in it?
*) Passing the offset of the archive header instead of the object
data. This is to make elf_rand happy, but is an interface pollution. I
can change the plugin to pass the offset of the object data itself,
but then I have to include ar.h in lto-elf.c to get sizeof (struct
ar_hdr). Is there an API in libelf to get an Elf* from a fd, offset
pair?

> Richard.
>

Cheers,
-- 
Rafael Ávila de Espíndola
-------------- next part --------------
A non-text attachment was scrubbed...
Name: archive.patch
Type: text/x-diff
Size: 6697 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20091102/6bc24322/attachment.bin>


More information about the Gcc-patches mailing list