This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] S/390: Fix two issues with the IFUNC optimized mem* routines
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: Andreas Krebbel <krebbel at linux dot vnet dot ibm dot com>, David Miller <davem at davemloft dot net>, aj at suse dot com, libc-alpha at sourceware dot org, Binutils <binutils at sourceware dot org>
- Date: Sun, 2 Sep 2012 13:06:28 -0700
- Subject: Re: [PATCH] S/390: Fix two issues with the IFUNC optimized mem* routines
- References: <503E009B.email@example.com> <CAMe9rOrmiF3VZOBNvEbMV5jFNog1-_EoPoT9rHTUQFsANaSD8w@mail.gmail.com> <503E3930.firstname.lastname@example.org> <email@example.com> <503F14A3.firstname.lastname@example.org> <CAMe9rOozW=4q_a=nmNvbZhsXooRZ4opvTTNtq2WHcGSSd2ONOw@mail.gmail.com> <CAMe9rOpc7KHMXk8xrQV3p2fAn-uTWZJ91R6k=DbCXENs43Kemw@mail.gmail.com> <5040CCC6.email@example.com> <CAMe9rOr2Vic9vENNbRf5_z22-kMS2Uu-6Lsgd_Xi6bctw6CF4w@mail.gmail.com> <50423CF8.firstname.lastname@example.org> <CAMe9rOor=+aUhtadjDWzT9gHJvteZouk7-cvF_U=k=2vdFgsNA@mail.gmail.com> <50427D29.email@example.com> <CAMe9rOpX6j=rcdtJwuL3XCmG+TrPxk01DkZ0MrxWzAMCy8Gdfirstname.lastname@example.org> <5043B674.email@example.com>
On Sun, Sep 2, 2012 at 12:41 PM, Richard Henderson <firstname.lastname@example.org> wrote:
> On 2012-09-02 07:50, H.J. Lu wrote:
>> A relax pass won't work properly for x86 without some surgery
>> since lang_relax_sections is called after bfd_elf_size_dynamic_sections
>> which calls elf_x86_64_allocate_dynrelocs to allocate GOT entries
>> and dynamic relocations. After it is done, it is not to easy to undo
>> the damage.
> Other targets keep usage counts of GOT entries live throughout relaxation.
> It becomes easy to adjust the GOT *after* bfd_elf_size_dynamic_sections
> has been called. Indeed, many targets require this ordering since some
> of the optimizations applied are true relaxations, and require knowledge
> of true displacements. And indeed, the reduction in GOT size may enable
> another relaxation pass, enabling further optimizations to succeed.
That is true. IA64 needs more than one pass to do it properly.
>> This is a separate issue. X86 backends also optimize
>> TLS relocations. Some compilers generate bad TLS
>> sequences which lead to corrupted output:
>> But there is no way to turn off the TLS optimization.
> ... because it was done in the wrong place. An excellent opportunity
> to move the TLS relaxations to a relaxation pass, wouldn't you agree?
I think it is overkill for x86 since all relocations targets can be reached.
I don't want to make big changes in relaxation codes for this.