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: "ld -r" on mixed IR/non-IR objects (


On Tue, Dec 7, 2010 at 3:15 PM, Cary Coutant <ccoutant@google.com> wrote:
>> Here is my proposal. ÂAny comments?
>
> We talked about ld -r a while back during the WHOPR project, and the
> two ways that the linker could work: (1) combine all the .o files and
> use the plugin to run LTRANS on the IR files, producing a pure,
> optimized, object file; and (2) combine the non-IR object files as ld
> -r normally would, and combine that result somehow with the IR from
> the other files, for later optimization. If I remember correctly,
> there was support for both modes of operation. The first mode is
> easily handled with the current design (untested as far as I know --
> there are probably bugs, and I'm not sure if we get the symbol
> visibility correct in those cases).

We considered it.  The problem is LTO performs the best when
generating the final executable/DSO.  That is we want the full IR in the
output of "ld -r".

> The second mode corresponds with your proposal here. It's complicated
> by the fact that it's difficult to tell, once the objects are
> combined, which compiled code came without corresponding IR. For this,
> I've got a suggestion that seems a bit simpler than your
> ".objectonly\004" section, based on an idea for something completely
> unrelated[1] that I've been pondering over for a while. Instead of
> embedding the non-IR objects into the mixed object file, let's instead
> produce an archive file with several members: one that contains the
> result of running ld -r on the non-IR objects in the link, and one
> member for each of the IR files (alternatively, exactly one member
> that contains the result of running ld -r on all of the IR objects).
> In order to make the archive such that a subsequent link loads all of
> the members unconditionally, I propose to add a special symbol
> ".FORCE" into the archive symbol table for each member; when the
> linker sees that symbol in the archive symbol table, it will load the
> corresponding member unconditionally.
>
>> Â Â Â â Object-only section:
>> Â Â Â Â Â Â Â Â Section name won't be generated by any tools, something like
>>".objectonly\004".
>> Â Â Â Â Â Â Â Â Contains non-IR object file.
>> Â Â Â Â Â Â Â Â Input is discarded after link.
>
> Please -- use a special section type, not a magic name.
>

As Dave pointed out, we need the magic section name for non-ELF
platform.  One main feature of my proposal is transparent:

# ld -r -o foo.o foo1.o foo2.o foo3.o ...
# ld -r o -bar.o bar1.o bar2.o bar3.o ...
...
# ld  -r o new.o foo.o bar.o ...

where foo.o, bar.o ... are mixed object files.  That is more user-friendly.
Projects like Linux kernel can take advantage of LTO with simple changes
to their Makefiles.


-- 
H.J.


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