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.
(In reply to emaste from comment #0) > 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.
BTW, does freebsd support Instruction Set Specific Shared Objects? https://docs.oracle.com/cd/E19683-01/817-3677/6mj8mbtd5/index.html
> 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.
(In reply to emaste from comment #3) > > 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.
> 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.
r308167