unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
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


  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).