From: Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>
To: Fangrui Song <i@maskray.me>
Cc: libc-alpha@sourceware.org, binutils@sourceware.org
Subject: Re: ifunc resolving
Date: Tue, 19 Jan 2021 15:59:54 +0100 [thread overview]
Message-ID: <87sg6xezv9.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <20210118220403.nzq6imfmaluuavfp@gmail.com> (Fangrui Song's message of "Mon, 18 Jan 2021 14:04:03 -0800")
* Fangrui Song:
> I have seen ifunc relocation activities on glibc and ld recently.
> https://sourceware.org/glibc/wiki/GNU_IFUNC is under-documented, some aspects
> have not been well-known, and there are a lot differences across architectures
> supporting ifunc, so I am sending this email hoping that these aspects can be
> clarified, toolchain developers can get on the same page, and documentation can
> be improved (if developers get confused at times, how could regular users
> comfortably use them? :) )
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.
* 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).
I do not think we have ever achieved consensus which position is the
correct one.
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.
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
next prev parent reply other threads:[~2021-01-19 15:00 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-18 22:04 ifunc resolving Fangrui Song
2021-01-18 22:53 ` H.J. Lu via Libc-alpha
2021-01-19 14:59 ` Florian Weimer via Libc-alpha [this message]
2021-01-19 22:31 ` Alan Modra via Libc-alpha
2021-01-20 9:33 ` Florian Weimer via Libc-alpha
2021-01-20 16:13 ` Zack Weinberg
2021-01-20 16:17 ` Florian Weimer via Libc-alpha
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
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87sg6xezv9.fsf@oldenburg.str.redhat.com \
--to=libc-alpha@sourceware.org \
--cc=binutils@sourceware.org \
--cc=fweimer@redhat.com \
--cc=i@maskray.me \
/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).