On Wed, Dec 1, 2010 at 3:06 PM, Cary Coutant <ccout...@google.com> wrote: >>> That is what "Discard all previous inputs" in stage 2 linking is for. >> >> But what does that mean? Are you saying that the linker interface to >> the plugin should change to work that way? If we do that, then we >> should change other aspects of the plugin interface as well. It could >> probably become quite a bit simpler. >> >> The only reason we would ever need to do a complete relink is if the LTO >> plugin can introduce arbitrary new symbol references. Is that ever >> possible? If it is, we need to rethink the whole approach. If the LTO >> plugin can introduce arbitrary new symbol references, that means that >> LTO plugin can cause arbitrary objects to be pulled in from archives. >> And that means that if we only run the plugin once, we are losing >> possible optimizations, because the plugin will never those new objects. >> >> My suspicion is that the LTO plugin can only introduce a small bounded >> set of new symbol references, namely those which we assume can be >> satisified from -lc or -lgcc. Is that true? > > Exactly. The plugin API was designed for this model -- if you want to > start the link all over again, you may as well stick with the collect2 > approach and enhance it to deal with archives of IR files.
Some compilers duplicates the whole linker symbol resolution in their "collect2" program to get it right. > The plugin API, as implemented in gold (not sure about gnu ld), does > maintain the original order of input files as far as symbol binding is > concerned. When IR files are claimed, the plugin provides the list of > symbols defined and referenced, and the linker builds the symbol table > as if those files were linked in at that particular spot in the > command line. When the compiler provides real definitions of those > symbols later, the real definitions simply replace the "placeholders" > that were left in the linker's symbol table. The only aspect of link > order that isn't maintained is the physical order of the sections in > memory. That is exactly the problem my proposal tries to address. > As Ian noted, if the compiler introduces new references that weren't > there before, the new references must be from a limited set of > libcalls that the backend can introduce, and those should all be > resolved with an extra pass through -lc or -lgcc. That's not exactly > pretty, but I don't see how it destroys the notion of link order -- > the only way those new symbols could have been resolved differently is > if a user library interposed definitions for the libcall, and those > certainly can't be what the compiler intended to bind to. In PR 12248, > I think it's questionable to claim that the compiler-introduced call > to __udivdi3 should not resolve to the version in libgcc. Sure, I > understand it's useful for library developers while debugging and > testing, but an ordinary user certainly can't count on his own > definition of that routine to get called -- the compiler might > generate the division inline, or call a different specialized version. > All of these routines are outside the user's namespace, and we should > be able to optimize without regard for what the user's libraries might > contain. > __udivdi3 is just an example. It can also happen to memcpy, or any library calls generated by GCC. I am enclosing a testcase for memcpy. -- H.J.
bug-2.tar.bz2
Description: BZip2 compressed data
