Implement filter library support (-F / --filter)

[emaste]

Bugzilla Link	33766
Resolution	FIXED
Resolved on	Jul 19, 2017 00:07
Version	unspecified
OS	FreeBSD
Blocks	#23588

Extended Description

FreeBSD recently added a dummy libdl as a filter library (https://reviews.freebsd.org/rS320872) to ease porting of software from Linux, which expects -ldl to work, and we'd like to support -F/--filter with lld (and presumably -f/--auxiliary also).

Filter library details are here: https://docs.oracle.com/cd/E19683-01/817-3677/chapter4-31738/index.html

Using the FreeBSD change as an example, to produce a filter library we add -F,libc.so.7. The primary effect is that the resulting shared object gains a DT_FILTER entry:

Dynamic section at offset 0xd30 contains 25 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.7]
0x000000000000000e (SONAME) Library soname: [libdl.so.1]
0x000000007fffffff (FILTER) Filter library: [libc.so.7]

When the runtime loader encounters this it uses the named filtee library (libc.so.7) to resolve symbols from the filter library.

[llvmbot]

and we'd like to support -F/--filter with
lld (and presumably -f/--auxiliary also).

Patch implementing -F/--filter is https://reviews.llvm.org/D35352,
and we already provide support for -f/--auxiliary.

[llvmbot]

BTW, does freebsd support Instruction Set Specific Shared Objects?

https://docs.oracle.com/cd/E19683-01/817-3677/6mj8mbtd5/index.html

[emaste]

BTW, does freebsd support Instruction Set Specific Shared Objects?

We do not have support today - our rtld does not expand $ISALIST.

Kostik will implement it for completeness if we can find a canonical list of possible values somewhere, but in practice GNU ifunc is much more likely to be the approach taken for this kind of use case.

[llvmbot]

BTW, does freebsd support Instruction Set Specific Shared Objects?

We do not have support today - our rtld does not expand $ISALIST.

Kostik will implement it for completeness if we can find a canonical list of
possible values somewhere, but in practice GNU ifunc is much more likely to
be the approach taken for this kind of use case.

Because of the popularity of linux?

I quite like the ISALIST idea. It is less flexible in theory, but should allow the support of non lazy binding too, which is pretty much impossible with ifunc.

[emaste]

Because of the popularity of linux?

Primarily because it seems cumbersome to have a half dozen or so individual filter libs, and because AFAICT $ISALIST hasn't been updated in several years, so there's a bunch of additional work that seemingly needs to be done to define appropriate recent microarch entries.

In practice we'd use this for things like a small handful of optimized string routines.

[llvmbot]

r308167