[ELF] - Implement filter library support (-F / --filter)
ClosedPublic

Authored by grimar on Thu, Jul 13, 4:55 AM.

Details

Summary

This is PR33766.

-F name
--filter=name
When creating an ELF shared object, set the internal DT_FILTER field to the specified name. This tells the dynamic linker that the symbol table of the shared object which is being created should be used as a filter on the symbol table of the shared object name.

If you later link a program against this filter object, then, when you run the program, the dynamic linker will see the DT_FILTER field. The dynamic linker will resolve symbols according to the symbol table of the filter object as usual, but it will actually link to the definitions found in the shared object name. Thus the filter object can be used to select a subset of the symbols provided by the object name.
(https://linux.die.net/man/1/ld).

Shared Objects as Filters:
https://docs.oracle.com/cd/E19683-01/817-3677/chapter4-31738/index.html

Diff Detail

Repository
rL LLVM
grimar created this revision.Thu, Jul 13, 4:55 AM

I believe -F / --filter can be used multiple times, as with -f.

grimar updated this revision to Diff 106427.EditedThu, Jul 13, 7:48 AM
  • Allow multiple standart filters.

(Behavior is inconsistent with GNU linkers/spec, but matches to what Oracle spec says).

ruiu added a comment.Thu, Jul 13, 8:58 AM

I don't think merging AuxiliaryList with FilterList is a good idea. Can you represent them as two separate vectors?

In D35352#808107, @ruiu wrote:

I don't think merging AuxiliaryList with FilterList is a good idea. Can you represent them as two separate vectors?

I can do that change tomorrow, though I can't say I would prefer splitting them.
This filters are very close: https://docs.oracle.com/cd/E19683-01/817-3677/chapter4-31738/index.html,
they have different behavior policies, but the same nature.

ruiu added a comment.Thu, Jul 13, 9:11 AM

The similarity in semantics doesn't imply that they should be represented as one unified list in code. It looks like representing them as plain StringRef vectors is more straightforward.

In D35352#808142, @ruiu wrote:

It looks like representing them as plain StringRef vectors is more straightforward.

That's probably true. I'll do that change.

grimar updated this revision to Diff 106597.Fri, Jul 14, 2:42 AM
  • Addressed review comments.
ruiu accepted this revision.Fri, Jul 14, 10:10 AM

LGTM

This revision is now accepted and ready to land.Fri, Jul 14, 10:10 AM

This LGTM.

test/ELF/as-needed-no-reloc.s
19 ↗(On Diff #106597)

Presumably these get committed with the llvm-readobj change

I've successfully tested this change imported into my FreeBSD work branch
https://github.com/emaste/freebsd/commit/12f8c0fd362c128c03acc9689c76d8c5d5c69dbe

One note, the ordering of the value tags differs wrt GNU ld. It shouldn't matter, just something I noticed.

GNU ld.bfd 2.17.50

  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]
 0x000000000000000c (INIT)               0x738
 0x000000000000000d (FINI)               0xa48
 0x0000000000000004 (HASH)               0x158
...

Patched lld

  Tag        Type                         Name/Value
 0x000000007fffffff (FILTER)             Filter library: [libc.so.7]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.7]
 0x000000000000000e (SONAME)             Library soname: [libdl.so.1]
 0x0000000000000007 (RELA)               0x6c0
 0x0000000000000008 (RELASZ)             96 (bytes)
...

(I originally put this comment on D35351 by accident.)

This revision was automatically updated to reflect the committed changes.