From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12233 invoked by alias); 26 Feb 2011 04:03:11 -0000 Received: (qmail 12223 invoked by uid 22791); 26 Feb 2011 04:03:10 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,TW_FD X-Spam-Check-By: sourceware.org Received: from dm-mail02.mozilla.org (HELO dm-mail02.mozilla.org) (63.245.208.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Feb 2011 04:03:05 +0000 Received: from desktop.lan (v74-nslb.mozilla.org [10.2.74.4]) (Authenticated sender: respindola@mozilla.com) by dm-mail02.mozilla.org (Postfix) with ESMTP id 1C4D682415A; Fri, 25 Feb 2011 20:02:53 -0800 (PST) Message-ID: <4D687B6C.1030301@mozilla.com> Date: Sat, 26 Feb 2011 04:03:00 -0000 From: =?ISO-8859-1?Q?Rafael_=C1vila_de_Esp=EDndola?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: binutils@sourceware.org CC: iant@google.com Subject: Re: [5/6][PATCH] Perform second link stage and ignore now-obsolete linker -pass-through= option. References: <4D684CB8.6020106@gmail.com> <4D684D00.70803@gmail.com> <4D684D69.7060907@gmail.com> In-Reply-To: <4D684D69.7060907@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00344.txt.bz2 On 2011-02-25 19:46, Dave Korn wrote: > > Hi list, > > This is the second main functional change, and it's really the only way to > resolve the problems caused by discrepancies between the initial set of > symbols returned by the plugin based on the LTO symtabs in the IR files, and > the actual set of symbols used and defined by the eventual object file(s) > added to the link after LTRANS. It's largely the same approach as HJ's > 2-stage link, except that it closes and reopens the existing input BFDs in > place, rather than adding a second set of input statements. This results in > some different behaviour between HJ's linker and this patched version. > > > ld/ChangeLog: > > 2011-02-20 Dave Korn <... > > PR ld/12365 > * ldcref.c (cref_hash_table_free): New function. > * ld.h (cref_hash_table_free): Add prototype. > * ldlang.c (lang_gc_sections): Dont de-exclude claimed file sections. > (set_exclude): New function. > (reopen_inputs): Likewise. Walk list of input objects, excluding > claimed (IR-only) files and archive members, then re-walk list, closing > and re-opening and re-adding the symbols from objects and libs. > (lang_process): After opening plugin-supplied objects and scanning > their library dependencies, tear down existing link, cref and > already-linked-section hashes, erase link_info input bfds list, finally > call reopen_inputs. > * plugin.c (plugin_opt_plugin_arg): Discard any instances of the > now-obsolete "-pass-through=" option if found. > > I know Ian would rather avoid this approach, but I don't think that there's > any other way to do LTO in LD without either rearchitecting BFD quite a bit. > We can't do symbol resolution without adding symbols from the LTO symtabs into > the linker hash table, but then after LTRANS we may have a different final set > of symbols present. There's no way to excise individual symbols from the > linker hash table in BFD, so you have to achieve the same effect by tearing > down the symbol table and rebuilding it without adding the unwanted symbols at > all second time round. That means you have to close and reopen all the BFDs, > because BFD backends cache pointers to hash table entries in the bfd's private > data, which are now stale once you've built a new symbol table. I can't see > any way around having to re-do at least this amount of work, but without it > we'll get bogus symbols in our final outputs, which is a real correctness issue. Ian, Assuming this is ok for bfd, would a patch implementing the same logic be ok for gold? It would be bad to have different interfaces in bfd ld and gold. > cheers, > DaveK > Cheers, Rafael