Mirror of the gdb mailing list
 help / color / mirror / Atom feed
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


  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