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


On Thu, Dec 2, 2010 at 6:52 AM, Ian Lance Taylor <iant@google.com> wrote:
> "H.J. Lu" <hjl.tools@gmail.com> writes:
>
>> On Wed, Dec 1, 2010 at 5:53 PM, Ian Lance Taylor <iant@google.com> wrote:
>>
>>> Or I'll rephrase: are there any cases for which using -pass-through for
>>> the set of libraries that the gcc driver automatically adds to the end
>>> of the link line would not be a complete solution?
>>>
>>> I'm not saying -pass-through is the solution we should be using. ?It's
>>> clearly a bit of a hack. ?However, I am asking the question seriously,
>>> because if we have to do a complete relink, then let's do a complete
>>> relink, but if we don't have to do one, let's definitely not.
>>
>> Nothing can't be solved with a hack :-).
>
> I propose that we add a new linker option: --plugin-callback. ?At each
> point where this option appears on the command line, the linker will
> call a new plugin callback entry point. ?The LTO plugin will replace the
> all_symbols_read callback with this one. ?We will have the gcc driver
> run the linker more or less like this:
>
> object-files -lc -lgcc --plugin-callback -lc -lgcc crtend.o crtn.o
>

I am not saying we should go with 2 stage linking. Just for clarification.
In 2 stage linking, the first stage only does symbol resolution. The complete
linking starts at the second stage.  So we don't do really complete relink
in 2 stage linking.


-- 
H.J.


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