This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[ping2][PATCH][BZ #14932] make dlsym return the newest symbol version


Ping!

On Mon, Jun 03, 2013 at 02:52:06PM +0530, Siddhesh Poyarekar wrote:
> Ping!
> 
> On Fri, May 17, 2013 at 01:04:42PM +0530, Siddhesh Poyarekar wrote:
> > On Fri, Apr 19, 2013 at 03:28:04PM -0700, Roland McGrath wrote:
> > > I don't recall paying attention to that issue at the time.
> > > Perhaps AJ will recall something about it.
> > > 
> > > Just from looking at the cited 1999 thread, I understand the concern
> > > that Geoff Keating was raising at the time.  I don't think it was so
> > > much a statement that the existing behavior was intentional, but just
> > > a statement that there is no answer that doesn't have some potential
> > > downside.  Really what it boils down to is that using dlsym (vs
> > > dlvsym) at all is essentially always wrong when the object being
> > > interrogated uses (or is not known not to use) symbol versioning.
> > > 
> > > The simple fact is that we don't know how many applications are
> > > (presumably unwittingly) depending on the old behavior and would be
> > > broken by a change, nor how many applications are presently broken and
> > > would be fixed by the change.  The closest we have to a way to be
> > > right about that is to introduce a new symbol version for dlsym so
> > > that old binaries get the old behavior.  But even that's not too
> > > likely to avoid application problems, because people just recompiling
> > > an old application probably have no idea which of the behaviors it
> > > implicitly expects.
> > > 
> > > There isn't even a very good answer to what the user code ought to be
> > > doing instead to avoid the whole problem.  It can use dlvsym, but that
> > > presupposes that it actually knows what symbol version to ask for.  At
> > > the time you compile a particular program or library, you can know
> > > this for the moment.  But there is no one thing you can write in the
> > > source code that will still be right after a future recompilation.
> > > (That is, unless you do something like roll your own configure check
> > > to determine the current default version at build time.)  We could
> > > conceivably make this easier in the future by doing something like
> > > generating a header file akin to gnu/lib-names.h that defines a macro
> > > for each and every public symbol in each library.
> > 
> > I think the core problem I'm trying to fix is the inconsistency in
> > dlsym behaviour, where it returns the latest version for all handles
> > except RTLD_NEXT.
> > 
> > Making this behaviour consistent is the best way forward IMO.  If one
> > wants an older symbol, the correct way is in fact to use dlvsym to ask
> > for the specific version.  Any application depending on the current
> > behaviour is depending on a bug, not a documented feature.
> > 
> > Siddhesh


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]