From: Florian Weimer <fweimer@redhat.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Binutils <binutils@sourceware.org>,
Alan Modra <amodra@gmail.com>, Nick Clifton <nickc@redhat.com>,
Richard Earnshaw <rearnsha@arm.com>
Subject: Re: [PATCH v3 2/2] elf: Add GNU_PROPERTY_1_NEEDED check
Date: Thu, 08 Jul 2021 09:27:12 +0200 [thread overview]
Message-ID: <87zguxw9in.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <CAMe9rOr9S9iacv3zQNUs+0aUEhS8Z8pk52zMoB9YzYpUCkgpNg@mail.gmail.com> (H. J. Lu's message of "Mon, 28 Jun 2021 04:55:19 -0700")
* H. J. Lu:
>> >> For (4), I think we need to set a different flag (or perhaps even
>> >> flags), and be really careful about what we do. I think an output file
>> >> that is an executable will never require indirect-extern-access, but it
>> >
>> > What did you mean by that? We need to compile executable with
>> > -fno-direct-extern-access for the whole scheme to work.
>>
>> indirect-extern-access imposes a requirement on executables, but
>> building an executable to comply with the new requirements will not
>
> That is correct.
>
>> impose anything on the rest of the link. I do not see the markup
>> covering that.
>
> The absence of the marker tells ld.so that copy relocation against
> protected symbols in the executable is incompatible with the shared
> library with the protected symbol AND the marker.
Maybe I don't completely understand the direction in which is is moving.
Is the idea to phase out copy relocations in general? Or just disable
them for protected symbols?
Thanks,
Florian
next prev parent reply other threads:[~2021-07-08 7:27 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-24 13:24 [PATCH v3 0/2] elf: Implement indirect external access marker H.J. Lu
2021-06-24 13:24 ` [PATCH v3 1/2] elf: Add GNU_PROPERTY_1_NEEDED H.J. Lu
2021-06-24 13:24 ` [PATCH v3 2/2] elf: Add GNU_PROPERTY_1_NEEDED check H.J. Lu
2021-06-25 14:10 ` Florian Weimer
2021-06-25 18:52 ` H.J. Lu
2021-06-28 8:46 ` Florian Weimer
2021-06-28 11:55 ` H.J. Lu
2021-07-08 7:27 ` Florian Weimer [this message]
2021-07-08 12:26 ` H.J. Lu
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87zguxw9in.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=amodra@gmail.com \
--cc=binutils@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=nickc@redhat.com \
--cc=rearnsha@arm.com \
/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).