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: Add STB_SECONDARY support


On Wed, Jul 04, 2012 at 07:00:38AM -0700, H.J. Lu wrote:
> On Tue, Jul 3, 2012 at 5:39 PM, Alan Modra <amodra@gmail.com> wrote:
> > Like I said, I'm sure you could devise a way to put your backup
> > functions in another shared library that is searched after libc.so.6
> > That's dead easy. ?Deeper nesting of shared libraries is a little more
> > difficult, due to breadth first library search, but still possible for
> > any given depth of libraries. ?I imagine this case would be rare
> > anyway.
> 
> Sure, we can do it on glibc with LD_DYNAMIC_WEAK.
> But I haven't found another easy way to achieve the same
> result

You don't need LD_DYNAMIC_WEAK with the scheme I proposed.  The normal
ELF shared library symbol resolution works.  The only difficulty is in
ensuring a backup library is searched last.

> STB_SECONDARY is my proposal and we have found
> some nice usages.

Well, STB_SECONDARY allows you to put your backup functions anywhere.

Other than that I see no advantage.  In fact, I think there are a
whole lot of disadvantages to the whole tool-chain needing to know
about another symbol binding.  For instance, won't users need to
compile their code differently?  And if you're marking source with
attributes, what happens when users manage to make only part of a
compilation unit secondary?  How does this new binding play with C++?
We know from past experience that there is a whole world of pain with
mismatched libstdc++.so and inline functions.  I see STB_SECONDARY as
another way to get things wrong.  Sorry.

-- 
Alan Modra
Australia Development Lab, IBM


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