RE: [patch] --filter option in ld: srcfix

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi Florian,

Responding to your idea about filtering...
I just checked the filtering. It does work as expected, means, I cannot build main.c using some new symbol, defined only in filtee.c, but not in filter.c. So the runtime won't use the full set of filtee's symbols, but just a subset, defined in the filter.

You can check my sample, attached to the previous email. Easy to use. Just rename build.txt to build.sh, and put the usual  #!/bin/bash on the top to build it. Then run "./prog".

I am completely open to change my wording.

Thanks,
Andrei

-----Original Message-----
From: Florian Weimer <fweimer@xxxxxxxxxx>
Sent: Wednesday, December 8, 2021 1:08 PM
To: PODOPLELOV Andrei <Andrei.PODOPLELOV@xxxxxxx>
Cc: mtk.manpages@xxxxxxxxx; linux-man@xxxxxxxxxxxxxxx; alx.manpages@xxxxxxxxx
Subject: Re: [patch] --filter option in ld: srcfix

* PODOPLELOV Andrei:

> I believe it would be beneficial to change it to something like:
>
>        --filter=name
>            When creating an ELF shared object (a "filter"), set the
>            internal DT_FILTER field to the specified name - another
>            ELF shared object (a "filtee"). This tells the dynamic linker
>            that the symbol table of the "filter" should be used to
>            select a subset of the symbols provided by the "filtee".
>
>            When you link a program against this "filter" and run it,
>            the dynamic linker will see the DT_FILTER field and resolve
>            symbols according to the symbol table of the "filter" object
>            as usual. However, when a certain symbol of the "filter" is
>            also present in "filtee", it will actually link to the
>            definition in the "filtee".

I think that's still misleading because to my knowledge, glibc does not implement any filtering.  Only the symbol search order is changed (what you describe in the second paragraph).

Thanks,
Florian

This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged.

If you are not one of the named recipients or have received this email in error,

(i) you should not read, disclose, or copy it,

(ii) please notify sender of your receipt by reply email and delete this email and all attachments,

(iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email.


Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer at 3DS.compliance-privacy@xxxxxxx<mailto:3DS.compliance-privacy@xxxxxxx>


For other languages, go to https://www.3ds.com/terms/email-disclaimer




[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux