From: Ian Lance Taylor <iant@google.com>
To: "Rafael Ávila de Espíndola" <respindola@mozilla.com>
Cc: binutils@sourceware.org
Subject: Re: [5/6][PATCH] Perform second link stage and ignore now-obsolete linker -pass-through= option.
Date: Sun, 27 Feb 2011 19:22:00 -0000 [thread overview]
Message-ID: <mcr39n9i8oz.fsf@google.com> (raw)
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")
Rafael Ávila de Espíndola <respindola@mozilla.com> writes:
>> What is the actual difference in behaviour?
>
> The main one is the requirement for -pass-through=.
It is already the case that gold does not require -pass-through=. In
fact, I've already modified the gcc plugin to ignore -pass-through= 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= 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
next prev parent reply other threads:[~2011-02-27 19:22 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-02-26 0:44 [PATCH,trunk+2.20] Fix issues in ld.bfd plugin interface [0/6] Dave Korn
2011-02-26 0:45 ` [PATCH,trunk+2.21] " Dave Korn
2011-02-26 0:45 ` [1/6][PATCH] Fix PE-COFF bug in orphan section alignment handling Dave Korn
2011-02-26 9:14 ` Alan Modra
2011-02-26 0:46 ` [5/6][PATCH] Perform second link stage and ignore now-obsolete linker -pass-through= option Dave Korn
2011-02-26 0:48 ` Dave Korn
2011-02-26 4:03 ` Rafael Ávila de Espíndola
2011-02-27 18:54 ` Ian Lance Taylor
2011-02-27 19:11 ` Rafael Ávila de Espíndola
2011-02-27 19:22 ` Ian Lance Taylor [this message]
2011-02-27 19:37 ` Rafael Ávila de Espíndola
2011-02-26 9:05 ` Alan Modra
2011-02-26 0:46 ` [2/6][PATCH] Do not use dummy bfd suffix for recognition, make it human-readable instead Dave Korn
2011-02-26 0:46 ` [3/6][PATCH] Revise linker plugin API to better preserve link order Dave Korn
2011-02-26 9:15 ` Alan Modra
2011-02-26 0:46 ` [4/6][PATCH] Fix issue from GCC PR47527: no ELF flags, EABI attribs, etc. in dummy IR BFD Dave Korn
2011-02-26 0:48 ` Dave Korn
2011-02-26 9:16 ` Alan Modra
2011-02-26 0:47 ` [6/6][PATCH] Respect symbol wrappers when computing symbol resolutions Dave Korn
2011-02-26 0:49 ` Dave Korn
2011-02-26 4:50 ` H.J. Lu
2011-02-26 9:28 ` Alan Modra
2011-02-26 0:47 ` [x/6][PATCH] Portability tweaks for LTO tests Dave Korn
2011-02-26 0:49 ` Dave Korn
2011-02-26 3:50 ` H.J. Lu
2011-02-26 5:33 ` H.J. Lu
2011-02-26 2:14 ` [PATCH,trunk+2.20] Fix issues in ld.bfd plugin interface [0/6] H.J. Lu
2011-02-26 3:37 ` Dave Korn
2011-02-26 3:48 ` H.J. Lu
2011-03-10 10:43 ` Dave Korn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=mcr39n9i8oz.fsf@google.com \
--to=iant@google.com \
--cc=binutils@sourceware.org \
--cc=respindola@mozilla.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).