From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2515 invoked by alias); 27 Feb 2011 19:22:52 -0000 Received: (qmail 2505 invoked by uid 22791); 27 Feb 2011 19:22:51 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 27 Feb 2011 19:22:45 +0000 Received: from kpbe12.cbf.corp.google.com (kpbe12.cbf.corp.google.com [172.25.105.76]) by smtp-out.google.com with ESMTP id p1RJMgrf004036 for ; Sun, 27 Feb 2011 11:22:42 -0800 Received: from pwj3 (pwj3.prod.google.com [10.241.219.67]) by kpbe12.cbf.corp.google.com with ESMTP id p1RJMeMv028416 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 27 Feb 2011 11:22:40 -0800 Received: by pwj3 with SMTP id 3so664505pwj.29 for ; Sun, 27 Feb 2011 11:22:40 -0800 (PST) Received: by 10.142.251.3 with SMTP id y3mr3603889wfh.384.1298834560176; Sun, 27 Feb 2011 11:22:40 -0800 (PST) Received: from coign.google.com ([216.239.45.130]) by mx.google.com with ESMTPS id z1sm4770284wfd.9.2011.02.27.11.22.38 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Feb 2011 11:22:39 -0800 (PST) From: Ian Lance Taylor To: Rafael =?utf-8?Q?=C3=81vila?= de =?utf-8?Q?Esp=C3=ADndola?= Cc: binutils@sourceware.org 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> <4D687B6C.1030301@mozilla.com> <4D6AA1E3.8040000@mozilla.com> Date: Sun, 27 Feb 2011 19:22:00 -0000 In-Reply-To: <4D6AA1E3.8040000@mozilla.com> ("Rafael =?utf-8?Q?=C3=81vila?= de =?utf-8?Q?Esp=C3=ADndola=22's?= message of "Sun, 27 Feb 2011 14:11:31 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true 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/msg00381.txt.bz2 Rafael =C3=81vila de Esp=C3=ADndola writes: >> What is the actual difference in behaviour? > > The main one is the requirement for -pass-through=3D. It is already the case that gold does not require -pass-through=3D. In fact, I've already modified the gcc plugin to ignore -pass-through=3D when using gold version 1.11 or greater (gold 1.11 will be in the binutils 2.21.1 release). > A quick summary of > the possible ways of handling mixed IL/ELF files when given a sequence > like ELF IL IL ELF IL IL ELF is > > 1) Combine every contiguous IL file sequence (ELF COMBINED_ELF1 ELF > COMBINED_ELF2 ELF) and conceptually restart the link. This would provide > the least differences when compared to an all ELF link. > > 2) Combine every IL file into a single ELF, put it in the place of the > first IL file (ELF COMBINED_ELF ELF ELF) and conceptually restart the > link. If I understand it correctly, this is where the bfd ld is going. > > 3) Same as before, but put the combined elf file in the end. > > 4) Same as before, but do not restart the link. This is what gold does > currently and requires the -pass-through option. I would say that right now gold approximately implements your option 2 (not option 4) and does not require the -pass-through=3D option. If the plugin does not introduce any new symbol definitions in the single ELF file that it creates, new symbol definitions which were not previously returned as IL symbols, then gold exactly implements option 2 (it's OK for the plugin to introduce new symbol references, gold will handle those correctly). New symbol definitions will not be handled correctly in the case where the symbol was previously defined by a .o or .a file seen after the first IL file. However, I think that is OK because I think it would be very dubious for a plugin to create an object file with a new symbol definition which the plugin did not previously report. Ian