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: PATCH: Fix linker plugin support for gnu linker


>>> By the same token, I have implemented 2 stage linking in GNU linker
>>> and it works with the current linker plugin ABI.
>>
>> But that is really not the same token. ?I am saying: the plugin was
>> designed to avoid 2 stage linking. ?You are saying: I can do 2 stage
>> linking with the plugin. ?That is true, but you can also do 2 stage
>> linking with a much simpler plugin.
>
> What I meant was "the work for 2 stage linking in GNU linker has
> already been done and it is already working."

Thanks to Dave, the work for 1-stage linking in the GNU linker has
already been done, too. You've ripped that out and replaced it, when
Ian's proposed fix for gold would also have fixed the 1-stage GNU
linker.

The link time difference isn't the only reason we wanted the current
plugin design. I argued earlier that with the 2-stage approach, the
compiler has fewer guarantees that the "whole program" it sees during
the optimization phase is actually the same whole program that ends up
being linked. The 1-stage approach, with accommodations for a small
set of compiler-support libraries, gets us closer to the ideal of
having the whole program visible to the optimizer.

>>> If you think this is a "rather unusual case" and the current
>>> design/implementation works for majority cases, I don't see
>>> big problems for GNU linker to do 2 stage linking and gold keeps
>>> the current behavior.
>>
>> I don't want gold to keep the current behaviour, because that is clearly
>> buggy (for an unusual case). ?I am suggesting that gold adopt the patch
>> I sent out (http://gcc.gnu.org/ml/gcc/2010-12/msg00347.html) which
>> solves all cases that I know about.

I'm still not convinced that the new plugin API is necessary -- simply
adding the extra pass-through libraries as needed would fix the
problem. In either case, a gcc driver change is still necessary. That
by itself would fix both linkers with the 1-stage approach, with no
changes to either linker.

-cary


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