From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24796 invoked by alias); 26 Feb 2011 00:46:59 -0000 Received: (qmail 24787 invoked by uid 22791); 26 Feb 2011 00:46:58 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,TW_FD X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Feb 2011 00:46:54 +0000 Received: by mail-ww0-f43.google.com with SMTP id 15so2101428wwe.12 for ; Fri, 25 Feb 2011 16:46:53 -0800 (PST) Received: by 10.227.144.131 with SMTP id z3mr2728038wbu.198.1298681213379; Fri, 25 Feb 2011 16:46:53 -0800 (PST) Received: from [192.168.2.99] (cpc2-cmbg8-0-0-cust61.5-4.cable.virginmedia.com [82.6.108.62]) by mx.google.com with ESMTPS id w25sm1026207wbd.17.2011.02.25.16.46.51 (version=SSLv3 cipher=OTHER); Fri, 25 Feb 2011 16:46:52 -0800 (PST) Message-ID: <4D684D69.7060907@gmail.com> Date: Sat, 26 Feb 2011 00:46:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "binutils@sourceware.org" Subject: [5/6][PATCH] Perform second link stage and ignore now-obsolete linker -pass-through= option. References: <4D684CB8.6020106@gmail.com> <4D684D00.70803@gmail.com> In-Reply-To: <4D684D00.70803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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/msg00333.txt.bz2 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. cheers, DaveK