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]

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


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]