This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: PATCH: Add STB_SECONDARY support
On Tue, Jul 10, 2012 at 12:04 AM, Alan Modra <amodra@gmail.com> wrote:
> 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.
Search order isn't easily controlled and glibc already supports
LD_DYNAMIC_WEAK.
>> 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.
>
STB_SECONDARY should be mainly used by compiler writers and
library developers. It should be transparent to end users.
As of partial secondary compilation, secondary is only applied to
definition. You only need to apply secondary to backup definition.
You can provide backup C++ class definition, which should be applied
to the whole class. The only difference is secondary will make it
dynamic weak.
--
H.J.