This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: GNU ld ifunc dynamic relocation order
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Binutils <binutils at sourceware dot org>, Alan Modra <amodra at gmail dot com>
- Date: Fri, 15 Nov 2013 16:23:20 -0800
- Subject: Re: GNU ld ifunc dynamic relocation order
- Authentication-results: sourceware.org; auth=none
- References: <20130327132430 dot GG14552 at bubble dot grove dot modra dot org> <20130327133442 dot GH14552 at bubble dot grove dot modra dot org>
On Wed, Mar 27, 2013 at 6:34 AM, Alan Modra <amodra@gmail.com> wrote:
> This part addresses -zcombreloc sorting. GNU ld currently sorts
> dynamic relocs for -zcombreloc (usually the default), and destroys any
> order the backend imposes.
>
> So here I add some parameters to elf_backend_reloc_type_class in order
> to give the backend some chance of distinguishing ifunc relocations
> from other types. It's not quite as simple as looking at the reloc to
> find a symbol index, then testing the type of symbol, because we
> currently don't have a mapping of output dynamic symbol index to
> hash table symbol entry. (A backend could generate such a map if
> necessary.) Instead, I make the assumption that backends will keep
> ifunc relocations in a separate section, so their reloc_type_class
> function can simply check for that section or sections.
>
> I also change the second dynamic reloc sort function to sort first on
> reloc class. Previously the sorting was first on low address of
> groups of relocs all against the same symbol. This should not make a
> great deal of difference to ld.so efficiency since by this stage we
> have excluded reloc_class_relative by the first sort function, and
> reloc_class_plt normally belong in .rel(a).plt, not .rel(a).dyn. So
> we should have only reloc_class_normal, reloc_class_copy and
> reloc_class_ifunc relocs, and unless I'm quite mistaken a given symbol
> won't appear in more than one of these classes.
>
> The third part of this series hasn't been completed yet, but will
> take care to order powerpc64 ifunc relocs as was done in part one for
> powerpc. I intend to leave other target modifications to their
> respective maintainers.
>
> * elf-bfd.h (enum elf_reloc_type_class): Add reloc_class_ifunc.
> (struct elf_backend_data <elf_backed_reloc_type_class>): Add
> bfd_link_info* and asection* params.
> (_bfd_elf_reloc_type_class): Likewise.
> * elf.c (_bfd_elf_reloc_type_class): Likewise.
> * elflink.c (elf_link_sort_cmp2): Sort first on reloc class.
> (elf_link_sort_relocs): Update elf_backed_reloc_type_class call.
> * elf32-ppc.c (ppc_elf_reloc_type_class): Return reloc_class_ifunc
> for any reliplt reloc. Don't return reloc_class_plt for
> R_PPC_REL24 and R_PPC_ADDR24.
> * elf64-ppc.c (allocate_got): Formatting.
> (ppc64_elf_reloc_type_class): Return reloc_class_ifunc for any
> reliplt reloc.
> * elf-m10300.c, * elf32-arm.c, * elf32-bfin.c, * elf32-cr16.c,
> * elf32-cris.c, * elf32-hppa.c, * elf32-i386.c, * elf32-lm32.c,
> * elf32-m32r.c, * elf32-m68k.c, * elf32-metag.c, * elf32-nios2.c,
> * elf32-s390.c, * elf32-sh.c, * elf32-sparc.c, * elf32-tilepro.c,
> * elf32-vax.c, * elf32-xtensa.c, * elf64-aarch64.c, * elf64-alpha.c,
> * elf64-hppa.c, * elf64-ia64-vms.c, * elf64-s390.c, * elf64-sparc.c,
> * elf64-x86-64.c, * elfnn-ia64.c, * elfxx-tilegx.c, * elfxx-tilegx.h:
> Add extra params to the various reloc_type_class functions.
>
Alan,
Where does PPC put IRELATIVE relocations? I tried to use
reloc_class_ifunc for x86. But it doesn't work since x86 has
IRELATIVE relocations in .rel.plt or .rela.plt section:
http://www.sourceware.org/bugzilla/show_bug.cgi?id=16178
Can you make it work for .rel.plt or .rela.plt sectio?
Thanks.
H.J.