From: Cary Coutant <ccoutant@gmail.com>
To: Vladimir Radosavljevic <Vladimir.Radosavljevic@imgtec.com>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>,
"jan.smets@nokia.com" <jan.smets@nokia.com>,
Petar Jovanovic <Petar.Jovanovic@imgtec.com>
Subject: Re: [PATCH][gold] PR 21152: Mips: Handle more relocations in relocatable link
Date: Wed, 15 Mar 2017 22:18:00 -0000 [thread overview]
Message-ID: <CAJimCsFuXqLsUYgYqgPqTjiKoJ3PDq93-uZT4-wHhqRKT-PXdg@mail.gmail.com> (raw)
In-Reply-To: <3060420525346945A0ADBD567348A917EF93C5ED@BADAG02.ba.imgtec.org>
> This patch adds support for more relocations in relocatable link. It also
> introduces get_lo16_rel_addend method for finding partnering LO16 relocation
> because there is a problem with current implementation when using --threads
> option.
What problem are you referring to? I'm guessing that you're thinking
you can't use the approach of pushing HI16 relocations onto a list
like Scan::local does with target->got16_addends_, because
relocate_special_relocatable can be called in multiple threads, and
thus cannot update the non-thread-specific list. Well, got16_addends_
ought to be a member of the Target::Scan class, which would make it
thread specific, but it doesn't really matter that much since
Scan::local() and Scan::global() always run single threaded. The same
idea, however, could be used if needed in Target::Relocate, but that
doesn't help with relocate_relocs since there is no Target::Scan or
Target::Relocate equivalent class. It also doesn't help because here
you're trying to look ahead to the paired LO16 while processing a
HI16, while in Scan::local(), it only needs to look back to the paired
HI16 while processing a LO16.
I'm not happy with the potentially quadratic behavior introduced by
get_lo16_rel_addend(), but I guess my real issue isn't with your patch
so much as with the MIPS ABI itself. When the ISA doesn't provide a
sufficiently large operand field for a full embedded addend, ELF
expects you to use RELA relocations. With REL relocations, the linker
is forced to pull ugly stunts like this.
Rather than change the prototype for relocate_special_relocatable(), I
think you'd be better off reimplementing the whole of
relocate_relocs(), similar to what the powerpc port did. If you do
that, you'll be able to make a first pass over the relocs and build a
table of LO16 relocs that you can consult efficiently when processing
the HI16 relocs on the second pass.
-cary
next prev parent reply other threads:[~2017-03-15 22:18 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-03-10 16:52 Vladimir Radosavljevic
2017-03-15 22:18 ` Cary Coutant [this message]
2017-03-16 18:25 ` Vladimir Radosavljevic
2017-03-17 3:47 ` Cary Coutant
2017-03-21 16:14 ` Vladimir Radosavljevic
2017-03-30 13:06 ` Maciej W. Rozycki
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=CAJimCsFuXqLsUYgYqgPqTjiKoJ3PDq93-uZT4-wHhqRKT-PXdg@mail.gmail.com \
--to=ccoutant@gmail.com \
--cc=Petar.Jovanovic@imgtec.com \
--cc=Vladimir.Radosavljevic@imgtec.com \
--cc=binutils@sourceware.org \
--cc=jan.smets@nokia.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).