From: Pedro Alves <palves@redhat.com>
To: Yury Gribov <y.gribov@samsung.com>, Doug Evans <dje@google.com>
Cc: chet.ramey@case.edu, bug-readline@gnu.org,
Vyacheslav Barinov <v.barinov@samsung.com>,
Yury Usishchev <y.usishchev@samsung.com>,
"gdb@sourceware.org" <gdb@sourceware.org>,
Jan Kratochvil <jan.kratochvil@redhat.com>
Subject: Re: [Bug-readline] [PATCH] Enable visibility annotations
Date: Wed, 20 Apr 2016 09:22:00 -0000 [thread overview]
Message-ID: <57174A3A.80303@redhat.com> (raw)
In-Reply-To: <57171B67.3040204@samsung.com>
On 04/20/2016 07:02 AM, Yury Gribov wrote:
> Pedro,
>
> Do you think the above is doable for gdb?
I don't know -- I'm already juggling too many balls in the
air, and I'm afraid that if that depends on me, it'll take a
while before I'll manage to try.
Since gdb's use of private symbols is not an isolated incident,
I don't think we should try to clean up all packages that make
use of private symbols, in a rush. Instead, I think readline
needs to take a staged approach:
- Export all the private symbols that programs are using today.
Simply accept today's reality. The dynamic symbol table of
libreadline.so still shrinks, precedent for visibility
annotations is still set, and private symbol leakage
is contained, because future software will no longer be
able to abuse all the other private symbols that are
not exported.
- Claim that the symbols may no longer be available in a
future release.
- Give time for packages to clean themselves up, and propose
any necessary new replacement APIs.
- Optionally, in the release after the next, mark the symbols
as deprecated with __attribute__((deprecated)), so packages
that abuse private symbols get a build-time warning.
- In some future release, stop exporting the symbols.
> That would of course leave the
> problem of linking older gdb with new readline which will need to be
> resolved by distros.
Right.
Thanks,
Pedro Alves
next prev parent reply other threads:[~2016-04-20 9:22 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-18 18:16 Doug Evans
2016-04-20 6:02 ` Yury Gribov
2016-04-20 9:22 ` Pedro Alves [this message]
2016-04-20 9:45 ` Yury Gribov
2016-04-20 10:19 ` Pedro Alves
2016-04-20 10:55 ` Yury Gribov
2016-04-20 15:30 ` Chet Ramey
2016-04-20 21:16 ` Chet Ramey
2016-04-22 14:43 ` Pedro Alves
2016-04-22 15:25 ` Chet Ramey
[not found] <570F38DD.1030703@samsung.com>
[not found] ` <570F3C7E.30005@samsung.com>
[not found] ` <570F7554.7070901@redhat.com>
[not found] ` <570FB04D.2060107@case.edu>
2016-04-14 15:19 ` Pedro Alves
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=57174A3A.80303@redhat.com \
--to=palves@redhat.com \
--cc=bug-readline@gnu.org \
--cc=chet.ramey@case.edu \
--cc=dje@google.com \
--cc=gdb@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=v.barinov@samsung.com \
--cc=y.gribov@samsung.com \
--cc=y.usishchev@samsung.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