From: Yury Gribov <y.gribov@samsung.com>
To: Pedro Alves <palves@redhat.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:45:00 -0000 [thread overview]
Message-ID: <57174FBC.7080909@samsung.com> (raw)
In-Reply-To: <57174A3A.80303@redhat.com>
On 04/20/2016 12:22 PM, Pedro Alves wrote:
> 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.
Agreed, that's my plan for now.
> - Claim that the symbols may no longer be available in a
> future release.
You mean just email respective package maintainers?
> - Give time for packages to clean themselves up, and propose
> any necessary new replacement APIs.
This would require significant expertise in readline though...
> - 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.
That won't help as these symbols are not present in headers anyway. All
users have their own private declarations.
> - 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:45 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
2016-04-20 9:45 ` Yury Gribov [this message]
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=57174FBC.7080909@samsung.com \
--to=y.gribov@samsung.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=palves@redhat.com \
--cc=v.barinov@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