[patch] --filter option in ld: srcfix

[patch] --filter option in ld: srcfix

[PODOPLELOV Andrei]

[-- Attachment #1: Type: text/plain, Size: 3661 bytes --]

Hello Michael,

First of all I should admit I am a big fan of your "The Linux Programming Interface" book. I've been Windows guy since mid-90th and your book helped me to become a local Linux expert.

Working recently on a bug in our product, happening on Ubuntu, but not on our official RHEL, I found that it caused by -filter option in ld. Unfortunately the description of this option in https://man7.org/linux/man-pages/man1/ld.1.html is not very clear and that delayed my resolution.
I was lucky to find https://docs.oracle.com/cd/E23824_01/html/819-0690/chapter4-4.html, containing a step-by-step sample, I played with, and figured how it all works. My final sample is attached.
In this change I want to emphasize the relationship between the two shared objects.

The current doc says:

       --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.

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".

Best Regards,

Andrei PODOPLELOV
Senior Software Architect - Customer Success, Spatial
Office: +1 508 305 5247
mailto:Andrei.PODOPLELOV@3ds.com
http://www.3ds.com/
Spatial Corp. | 310 Interlocken Parkway, Suite 200 | Broomfield, CO 80021 | United States

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@3ds.com<mailto:3DS.compliance-privacy@3ds.com>


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

[-- Attachment #2: ld --filter option.zip --]
[-- Type: application/x-zip-compressed, Size: 924 bytes --]

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

[Florian Weimer]

* 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

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

[PODOPLELOV Andrei]

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@redhat.com>
Sent: Wednesday, December 8, 2021 1:08 PM
To: PODOPLELOV Andrei <Andrei.PODOPLELOV@3ds.com>
Cc: mtk.manpages@gmail.com; linux-man@vger.kernel.org; alx.manpages@gmail.com
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@3ds.com<mailto:3DS.compliance-privacy@3ds.com>


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

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

[Florian Weimer]

* PODOPLELOV Andrei:

> 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.

Looks like ld (the link editor) has filtering,

Try linking with -Wl,-z,undefs, I expect you will see that the symbol is
available at run time.

Thanks,
Florian

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

[PODOPLELOV Andrei]

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

Hi Florian,

Yes, I can build the executable with the suggested option. However, when I run it, I get SEGFAULT. That's exactly what should happen according to the docs.

See attached sample. I had to rename build.sh and remove #!/bin/bash from the top due to the corporate email restrictions.

My proposal does not change the meaning, but makes it more clear.

Thanks,
Andrei

-----Original Message-----
From: Florian Weimer <fweimer@redhat.com>
Sent: Thursday, December 9, 2021 8:36 AM
To: PODOPLELOV Andrei <Andrei.PODOPLELOV@3ds.com>
Cc: mtk.manpages@gmail.com; linux-man@vger.kernel.org; alx.manpages@gmail.com
Subject: Re: [patch] --filter option in ld: srcfix

* PODOPLELOV Andrei:

> 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.

Looks like ld (the link editor) has filtering,

Try linking with -Wl,-z,undefs, I expect you will see that the symbol is available at run time.

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@3ds.com<mailto:3DS.compliance-privacy@3ds.com>


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

[-- Attachment #2: ld --filter option.zip --]
[-- Type: application/x-zip-compressed, Size: 1032 bytes --]