This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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: Update LTO plugin interface


>>> Another way to do this would be to put a marker in the command line
>>> that identifies where those libraries begin, and the linker could just
>>> go back and rescan those libraries if needed, before the final layout
>>> of the endcaps.
>>
>> I like that idea in general, but the difficulty is knowing where to put
>> the marker. ?E.g., the user is going to specify -lm, and we are going to
>> need to rescan it. ?If the user writes -lm -lmylib1 -lmylib2 we want to
>> rescan -lm but we don't really need to rescan mylib1 and mylib2.
>
> All those complexities make 2 stage linking more attractive. ?I
> think I can implement it in GNU linker with the current plugin API.
>
> Linker just needs to remember the command line options, including
>
> --start-group/--end-group
> -as-needed/--no-as-needed
> --copy-dt-needed-entries/--no-copy-dt-needed-entries
>
> in stage 1.
>
> In stage 2, it will place LTO trans files before the first IR file
> claimed by plugin and process the command line options.
>
> --whole-archive may need some special handling. ?Archives
> after --whole-archive will be ignored in stage 2.

It seems to me that we just need to add a few more libraries as
pass-through libraries, being careful to add a pass-through option
only for libraries that are already on the command line. How does that
add up to "all those complexities"?

With what you've written here, you've just added to the complexity of
your proposed solution, which makes it a much bigger change --
especially since what you're proposing will require changes in both
linkers. Adding pass-through options is a gcc driver change only.

The pass-through option may be seen as a hack, but I don't think it's
that big of a hack, and it does work. I don't see it as fundamentally
different from adding an option to mark runtime support libraries --
the difference is really just syntax.

In the long term, I'd prefer to see improvements more along the lines
of what I've suggested earlier in this thread -- define a set of
runtime support routines that the backend can generate calls to, and
make those known to the linker so that they can be located during the
first pass. That's the best way to ensure that we have a complete
picture of the whole program for the optimizer.

For now, I think it's sufficient to fix the driver to add the
necessary pass-through options, and maybe gnu ld needs to be fixed to
handle the crtend files correctly. We also should address Jan's
concerns with COMDAT.

-cary


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