This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

> Maybe - but that's going to make a collect2 implementation harder
> as it would need to communicate via the command-line.

Can we at least have support for something like


meaning the file in foo.a starting at offset 123 and having size 15? The
linker plugin currently doesn't know the file name and I would like to
avoid having the plugin parse the archive header.

>> *) Correct implementation in collect2 is not going to be simple, since
>> collect2 doesn't know which members are going to be used.
> Well, collect2 uses nm at the moment to decide which .o files have
> lto data - it could as well use nm to decide which ar members have
> lto data (which is what I would do here). ÂThe alternative would
> of course be to pass the whole archive to lto1 and let it discover
> which members to use and which not.

My preferences is to keep as much stuff out of lto1 as possible, so I would
vote for having only IL files passed to lto1. Note that collect2 would have
to know the files without IL anyway so that it would pass them to the
final link.

Is it really unacceptable to require gold for using IL files in archives? Maybe
the best solution is to add plugin support to gnu LD. I already added a
minimal support to BFD so that nm and ar can use the IL symbol table.

> Yeah ;) ÂI'll investigate how difficult collect2 support would be.

Do consider patching GNU ld or moving to gold instead :-)

I will now thy to code a patch to the plugin for using foo.a@1234:15 and adapt
your patch for it. Lets see if works :-)

> Richard.

Rafael Ãvila de EspÃndola

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]