From: "H.J. Lu" <hjl.tools@gmail.com>
To: Michael Matz <matz@suse.de>
Cc: "Fāng-ruì Sòng" <maskray@google.com>,
llvm-dev@lists.llvm.org, "GCC Development" <gcc@gcc.gnu.org>,
"GNU C Library" <libc-alpha@sourceware.org>,
"GNU gABI gnu-gabi" <gnu-gabi@sourceware.org>,
Binutils <binutils@sourceware.org>
Subject: Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
Date: Tue, 22 Jun 2021 07:30:43 -0700 [thread overview]
Message-ID: <CAMe9rOr-+Hb4jCf4DdxWLX3fEPFShbYtUhuJUmjqVvVhBJP1-g@mail.gmail.com> (raw)
In-Reply-To: <alpine.LSU.2.22.394.2106211429080.6035@wotan.suse.de>
On Mon, Jun 21, 2021 at 7:36 AM Michael Matz <matz@suse.de> wrote:
>
> Hello,
>
> On Thu, 17 Jun 2021, H.J. Lu via Gcc wrote:
>
> > > > • Disallow copy relocation against definition with the STV_PROTECTED
> > > > visibility in the shared library with the marker.
> > >
> > > If this is for GNU ld x86 only, I'm fine with it:)
> > >
> > > gold and ld.lld just emit an error unconditionally. I think non-x86
> > > GNU ld ports which never support "copy relocations on protected data
> > > symbols" may want to make the diagnostic unconditional as well.
> > > Well, while (Michael Matz and ) I think compatibility check for "copy
> > > relocations on protected data symbols" is over-engineering (and
> > > Alan/Cary think it was a mistake), if you still want to add it, it is
> > > fine for me...
> > > For Clang, I hope we will not emit such a property, because Clang
> > > never supports the "copy relocations on protected data symbols"
> > > scheme.
> >
> > The issue is that libfoo.so used in link-time can be different from
> > libfoo.so at run-time. The symbol, foobar, in libfoo.so at link-time
> > has the default visibility. But foobar in libfoo.so at run-time can be
> > protected. ld.so should detect such cases which can lead to run-time
> > failures.
>
> Yes, but I think we can _unconditionally_ give an error in this case, even
> without a marker. I view restricting visiblity of a symbol in furture
Unconditionally issuing an error can be an option, but mandatory.
Otherwise working binary today will fail to run tomorrow.
> versions of shared libraries to be an ABI change, hence it has to be
> something that either requires a soname bump or at the very least symbol
To support existing binaries, we need a soname bump.
> versioning with the old version staying on default visibility.
Symbol versioning doesn't work here since both symbols are at
the same address.
> Compare the situation to one where the old libfoo.so provided a symbol
> bar, and the new one doesn't (sort of very restricted visiblity). ld.so
> will unconditionally give an error. I don't see this situation materially
> different from bar's visibility be changed from default to protected.
>
> > > I think this can be unconditional, because the "pointer equality for
> > > STV_PROTECTED function address in -shared" case hasn't been working
> > > for GNU ld for at least 20 years... Many ports don't even produce a
> > > dynamic relocation.
> >
> > True. But see above. You may not care about such use cases. But I
> > believe that ld.so should not knowingly and silently allow such run-time
> > failure to happen.
>
> Agreed, but giving an error message unconditionally wouldn't be silent.
>
>
> Ciao,
> Michael.
--
H.J.
next prev parent reply other threads:[~2021-06-22 14:31 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-13 17:06 H.J. Lu
2021-01-21 15:02 ` H.J. Lu
2021-01-21 21:42 ` Fangrui Song
2021-04-17 12:48 ` H.J. Lu
2021-04-17 18:25 ` Fangrui Song
2021-04-17 19:05 ` H.J. Lu
2021-06-17 18:59 ` H.J. Lu
2021-06-17 19:38 ` [llvm-dev] " Fangrui Song
2021-06-17 19:45 ` H.J. Lu
2021-06-17 20:25 ` Fāng-ruì Sòng
2021-06-17 23:01 ` H.J. Lu
2021-06-18 0:06 ` Fāng-ruì Sòng
2021-06-18 0:24 ` H.J. Lu
2021-06-18 0:49 ` Fāng-ruì Sòng
2021-06-18 2:40 ` H.J. Lu
2021-06-21 14:35 ` Michael Matz
2021-06-22 14:30 ` H.J. Lu [this message]
2021-06-22 14:54 ` Michael Matz
2021-06-18 2:45 ` H.J. Lu
2021-06-18 15:38 ` RFC: Add GNU_PROPERTY_1_NEEDED H.J. Lu
2021-06-18 21:34 ` [llvm-dev] " Fangrui Song
2021-06-19 1:09 ` 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=CAMe9rOr-+Hb4jCf4DdxWLX3fEPFShbYtUhuJUmjqVvVhBJP1-g@mail.gmail.com \
--to=hjl.tools@gmail.com \
--cc=binutils@sourceware.org \
--cc=gcc@gcc.gnu.org \
--cc=gnu-gabi@sourceware.org \
--cc=libc-alpha@sourceware.org \
--cc=llvm-dev@lists.llvm.org \
--cc=maskray@google.com \
--cc=matz@suse.de \
/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).