This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: LTO vs static library archives [was Re: lto1: internal compiler error: in lto_symtab_merge_decls_1, at lto-symtab.c:549]
> Well, we'd then need to re-architect the symbol merging and
> LTO unit read-in to properly honor linking semantics (drop
> a LTO unit from an archive if it doesn't resolve any unresolved
> symbols). I don't know how easy that will be, but it shouldn't
> be impossible at least.
We also should keep in mind that we really ought to be able to produce LTO .o files
without actual assembly in, so either we should not tie this too much with linking
process anyway or we need to output fake symbols into the LTO .o file when assembly
is not done.
(I guess one can just output empty variables and functions, but then .o will link
without LTO and lead to wrong code).
This is IMO quite important feature, we don't want to double compile times forever.
Honza
>
> > ?I'm sketching a plan where collect2 invokes 'ld' as if to do an ordinary
> > non-LTO link, but passes it a flag like "--lto-assist" which causes it to
> > output a list of just the archive members that it actually needs to complete
> > the link, in response file "filename.a@offset" format. ?ISTM that this is the
> > simplest method to avoid recompiling entire archives (sort of building a
> > linker into the compiler!), and I guess I should also make it check for an LTO
> > marker (whether symbol or section) and only output those members that actually
> > contain any LTO data.
>
> Yes - that would be basically a linker plugin without plugin support.
> And I'd go even further and have LD provide a complete symbol
> resolution set like we get from the gold linker-plugin.
>
> That wouldn't help for old or non-gnu LDs of course.
>
> > ?Making lto1 understand archives seems logical at first, but I don't think
> > it's much use without knowing which archive members we want in advance, and in
> > that case the existing code that reads a single archive member by pretending
> > it's an ordinary object file with a constant offset from the start of file
> > marker already does all we need, or so it seems to me.
>
> I think we should try without lto1 understanding archives first
> (or we are basically re-implementing a linker in lto1).
>
> Richard.
>
> > ? ?cheers,
> > ? ? ?DaveK
> >
> >