ifunc resolving
Alan Modra
amodra@gmail.com
Tue Jan 19 22:31:53 GMT 2021
More information about the Binutils mailing list
Tue Jan 19 22:31:53 GMT 2021
- Previous message (by thread): ifunc resolving
- Next message (by thread): ifunc resolving
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Tue, Jan 19, 2021 at 03:59:54PM +0100, Florian Weimer via Binutils wrote: > We have two positions that still need to be reconciled: > > * IFUNC resolvers must not themselves have relocation dependencies > because they can be called at any time during relocation. This > restricts the functionality available to an IFUNC resolver. On many architectures this cannot be achieved without hand-crafted assembly. The reason is obvious. Ifunc resolvers return an address. Compilers load addresses from the GOT, particularly for PIC. GOT entries need relocation. > * IFUNC resolvers may have relocation dependencies, but they may only be > called after the object that contains them has been relocated. This > restricts how IFUNC symbols can be used (interposition is limited, > correct dependency ordering via DT_NEEDED is required). No interposition in practice, because the object doing the interposing is almost always relocated later. > I do not think we have ever achieved consensus which position is the > correct one. There is a third possibility. If ld.so defers all irelative and other relocations using ifunc symbols until all non-ifunc relocations have been performed, globally, then ifunc resolvers would only have the restriction that they not call other ifuncs. That idea was floated a very long time ago. For some reason it is too hard or too slow to do in ld.so. > We have removed several IFUNC resolvers with IFUNC dependencies from > glibc itself because we could not follow the interposition/dependency > rules for the second approach. Right, I'm inclined to say ifunc has a fatal design flaw without deferred relocation processing. If it's too hard for glibc itself, it's too hard for anyone to use anywhere. > Due to the x86-specific checks we have, those architectures currently > land in the second category. I do not know if other architecture > maintainers agree. > > Thanks, > Florian > -- > Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, > Commercial register: Amtsgericht Muenchen, HRB 153243, > Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael O'Neill -- Alan Modra Australia Development Lab, IBM
- Previous message (by thread): ifunc resolving
- Next message (by thread): ifunc resolving
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list