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 1/3] elf: Allow dlopen of filter object to work [BZ #16272]


* David Kilroy:

>> Florian Weimer
>> 
>> * David Kilroy:
>> 
>> >> Is there an expectation that libinternal interposes symbols in libA
>> >> etc., perhaps with more efficient implementations?  And if not, a
>> >> fallback implementation in libA etc. is used?  This is clearly not
>> >> supported by the Solaris filter feature (as documented).
>> >
>> > I'm not sure what you mean here. Libinternal.so is expected to supply
>> > the implementations for the symbols in libA.so. Ideally we wouldn't
>> > pick up other symbols from libinternal, but this is not an issue for
>> us.
>> > If libinternal.so were to use IFUNC relocations for libA's symbols, I
>> > would hope it works, but I don't think that's being done.
>> 
>> I mean something like this.  libA defines f1, f2, f3.  libinternal
>> replaces f1 and f3 with optimized implementations, but not f2.
>> Applications which call f2 are expected to get the unoptimized
>> implementation in f2.
>
> Ah, no we don't do that. Our filter libraries would only contains stubs.
> The real implementation for all functions would live in libinternal.so.

In this case, I think you should reconsider the use of linker scripts
referencing stub objects.  I still think they provide the functionality
you need.  You even need to load fewer objects at run time. 8-)

Thanks,
Florian


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