Fāng-ruì Sòng via llvm-dev
2021-Jun-18 00:49 UTC
[llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu <hjl.tools at gmail.com> wrote:> > On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > On 2021-06-17, H.J. Lu wrote: > > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > >> > > >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools at gmail.com> wrote: > > >> > > > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray at google.com> wrote: > > >> > > > > >> > > On 2021-06-17, H.J. Lu via llvm-dev wrote: > > >> > > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu <hjl.tools at gmail.com> wrote: > > >> > > >> > > >> > > >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools at gmail.com> wrote: > > >> > > >> > > > >> > > >> > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > > >> > > >> > > > >> > > >> > #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 > > >> > > >> > #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > > >> > > >> > > > >> > > >> > A bit in the output pr_data field is set only if it is set in all > > >> > > >> > relocatable input pr_data fields. If all bits in the the output > > >> > > >> > pr_data field are zero, this property should be removed from output. > > >> > > >> > > > >> > > >> > If the bit is 1, all input relocatables have the feature. If the > > >> > > >> > bit is 0 or the property is missing, the info is unknown. > > >> > > > > >> > > How to use AND in practice? > > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o > > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object > > >> > > files written in assembly? > > >> > > > > >> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > > >> > > >> > > > >> > > >> > #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > > >> > > >> > #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff > > >> > > >> > > > >> > > >> > A bit in the output pr_data field is set if it is set in any > > >> > > >> > relocatable input pr_data fields. If all bits in the the output > > >> > > >> > pr_data field are zero, this property should be removed from output. > > >> > > >> > > > >> > > >> > If the bit is 1, some input relocatables have the feature. If the > > >> > > >> > bit is 0 or the property is missing, the info is unknown. > > >> > > >> > > > >> > > >> > The PDF is at > > >> > > >> > > > >> > > >> > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > > >> > > >> > > > >> > > >> > -- > > >> > > >> > H.J. > > >> > > >> > > >> > > >> Here is the binutils patch to implement it. > > >> > > >> > > >> > > > > > >> > > >If there are no objections, I will check it in tomorrow. > > >> > > > > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be > > >> > > very kind of you if you can collect more use cases before generalizing > > >> > > this into a non-arch-specific GNU PROPERTY. > > >> > > > > >> > > The "copy relocations on protected data symbols" thing is x86 specific > > >> > > and only applies with gcc+GNU ld+glibc. > > >> > > Non-x86 architectures don't have this thing. > > >> > > gold doesn't have this thing. > > >> > > clang doesn't have this thing. > > >> > > > >> > It will be used to remove copy relocation and implement canonical function > > >> > pointers, which will benefit protected data and function. > > >> > > >> The action items in > > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281 > > >> can be applied without a GNU PROPERTY. > > >> > > >> If we want to enforce the link-time check that a shared object is no longer > > >> compatible with copy relocations, just make the shared object's non-weak > > >> definitions protected, and add a GNU ld diagnostic like gold > > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823) > > >> > > >> --- > > >> > > >> For functions, > > >> > > >> On x86-64, gcc -fpic has been using leaq addr()(%rip), %rax since at least > > >> 4.1.2 (oldest gcc I can find on godbolt): > > >> > > >> __attribute__((visibility("protected"))) > > >> void *addr() { return (void*)addr; } > > >> > > >> // a protected non-definition declaration is the same. > > >> > > >> // while asm(".protected addr") can use GOT, it is super rare if ever exists > > >> // outside glibc elf/vis*.c > > >> > > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have > > >> the same diagnostic: > > >> > > >> relocation R_X86_64_PC32 against protected function `addr' can not > > >> be used when making a shared object > > >> > > >> I think we can assert that taking the address of a protected function > > >> never works with GNU ld. > > >> So no compatibility concern. > > >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html) > > >> doesn't need any GNU PROPERTY. > > >> > > >> --- > > >> > > >> For variables, if an object file/archive member does not have GNU PROPERTY, do > > >> you consider it incompatible with "single global definition"? That is why I > > >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members > > >> written in assembly. > > >> > > >> If you consider such an object compatible with "single global definition", I > > >> don't see why a GNU PROPERTY is needed. > > >> > > >> If you consider such an object incompatible with "single global definition", I > > >> don't see how "single global definition" benefits can be claimed giving so many > > >> prebuilt object files without GNU PROPERTY. > > > > > >Please see the slides in > > > > > >https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8 > > > > > >which includes > > > > > >Dynamic Linker for Single Global Definition > > >• Check the single global definition marker on all components, the executable > > >and its dependency shared libraries. > > >• Issue an error/warning if the marker is not consistent on all components. > > > > This is not appealing from a compatibility point of view. > > It is common that a system has mixed shared objects: > > > > -fsingle-global-definition => a.so (marker value 1) > > no -fsingle-global-definition => b.so (marker value 0 or no marker) > > Issuing a warning will be annoying. > > > > I updated my proposal to > > Dynamic Linker for Single Global Definition > • Check the single global definition marker on all components, the executable > and its dependency shared libraries.I find that I forgot (in so many of my previous messages) to mention that the name "single global definition" may give a false impression. For example, a dynamic STV_DEFAULT STB_WEAK/STB_GLOBAL symbol defined in a shared object can still be interposed.> • Disallow copy relocation against definition with the STV_PROTECTED > visibility in the shared library with the marker.If this is for GNU ld x86 only, I'm fine with it:) gold and ld.lld just emit an error unconditionally. I think non-x86 GNU ld ports which never support "copy relocations on protected data symbols" may want to make the diagnostic unconditional as well. Well, while (Michael Matz and ) I think compatibility check for "copy relocations on protected data symbols" is over-engineering (and Alan/Cary think it was a mistake), if you still want to add it, it is fine for me... For Clang, I hope we will not emit such a property, because Clang never supports the "copy relocations on protected data symbols" scheme.> • For systems without function descriptor: > • Disallow non-GOT function pointer reference in executable without > the marker to the > definition with the STV_PROTECTED visibility in a shared library with > the marker.I think this can be unconditional, because the "pointer equality for STV_PROTECTED function address in -shared" case hasn't been working for GNU ld for at least 20 years... Many ports don't even produce a dynamic relocation. I don't mind if you add it just for symmetry, but it just feels unneeded.> • Use the address of the function body as function pointer on functions with the > STV_PROTECTED visibility, which are defined in shared libraries with the marker.> > -- > H.J.
H.J. Lu via llvm-dev
2021-Jun-18 02:40 UTC
[llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
On Thu, Jun 17, 2021 at 5:49 PM Fāng-ruì Sòng <maskray at google.com> wrote:> > On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu <hjl.tools at gmail.com> wrote: > > > > On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > > > On 2021-06-17, H.J. Lu wrote: > > > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > > >> > > > >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools at gmail.com> wrote: > > > >> > > > > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray at google.com> wrote: > > > >> > > > > > >> > > On 2021-06-17, H.J. Lu via llvm-dev wrote: > > > >> > > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu <hjl.tools at gmail.com> wrote: > > > >> > > >> > > > >> > > >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools at gmail.com> wrote: > > > >> > > >> > > > > >> > > >> > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > > > >> > > >> > > > > >> > > >> > #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 > > > >> > > >> > #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > > > >> > > >> > > > > >> > > >> > A bit in the output pr_data field is set only if it is set in all > > > >> > > >> > relocatable input pr_data fields. If all bits in the the output > > > >> > > >> > pr_data field are zero, this property should be removed from output. > > > >> > > >> > > > > >> > > >> > If the bit is 1, all input relocatables have the feature. If the > > > >> > > >> > bit is 0 or the property is missing, the info is unknown. > > > >> > > > > > >> > > How to use AND in practice? > > > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o > > > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object > > > >> > > files written in assembly? > > > >> > > > > > >> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > > > >> > > >> > > > > >> > > >> > #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > > > >> > > >> > #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff > > > >> > > >> > > > > >> > > >> > A bit in the output pr_data field is set if it is set in any > > > >> > > >> > relocatable input pr_data fields. If all bits in the the output > > > >> > > >> > pr_data field are zero, this property should be removed from output. > > > >> > > >> > > > > >> > > >> > If the bit is 1, some input relocatables have the feature. If the > > > >> > > >> > bit is 0 or the property is missing, the info is unknown. > > > >> > > >> > > > > >> > > >> > The PDF is at > > > >> > > >> > > > > >> > > >> > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > > > >> > > >> > > > > >> > > >> > -- > > > >> > > >> > H.J. > > > >> > > >> > > > >> > > >> Here is the binutils patch to implement it. > > > >> > > >> > > > >> > > > > > > >> > > >If there are no objections, I will check it in tomorrow. > > > >> > > > > > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be > > > >> > > very kind of you if you can collect more use cases before generalizing > > > >> > > this into a non-arch-specific GNU PROPERTY. > > > >> > > > > > >> > > The "copy relocations on protected data symbols" thing is x86 specific > > > >> > > and only applies with gcc+GNU ld+glibc. > > > >> > > Non-x86 architectures don't have this thing. > > > >> > > gold doesn't have this thing. > > > >> > > clang doesn't have this thing. > > > >> > > > > >> > It will be used to remove copy relocation and implement canonical function > > > >> > pointers, which will benefit protected data and function. > > > >> > > > >> The action items in > > > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281 > > > >> can be applied without a GNU PROPERTY. > > > >> > > > >> If we want to enforce the link-time check that a shared object is no longer > > > >> compatible with copy relocations, just make the shared object's non-weak > > > >> definitions protected, and add a GNU ld diagnostic like gold > > > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823) > > > >> > > > >> --- > > > >> > > > >> For functions, > > > >> > > > >> On x86-64, gcc -fpic has been using leaq addr()(%rip), %rax since at least > > > >> 4.1.2 (oldest gcc I can find on godbolt): > > > >> > > > >> __attribute__((visibility("protected"))) > > > >> void *addr() { return (void*)addr; } > > > >> > > > >> // a protected non-definition declaration is the same. > > > >> > > > >> // while asm(".protected addr") can use GOT, it is super rare if ever exists > > > >> // outside glibc elf/vis*.c > > > >> > > > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have > > > >> the same diagnostic: > > > >> > > > >> relocation R_X86_64_PC32 against protected function `addr' can not > > > >> be used when making a shared object > > > >> > > > >> I think we can assert that taking the address of a protected function > > > >> never works with GNU ld. > > > >> So no compatibility concern. > > > >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html) > > > >> doesn't need any GNU PROPERTY. > > > >> > > > >> --- > > > >> > > > >> For variables, if an object file/archive member does not have GNU PROPERTY, do > > > >> you consider it incompatible with "single global definition"? That is why I > > > >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members > > > >> written in assembly. > > > >> > > > >> If you consider such an object compatible with "single global definition", I > > > >> don't see why a GNU PROPERTY is needed. > > > >> > > > >> If you consider such an object incompatible with "single global definition", I > > > >> don't see how "single global definition" benefits can be claimed giving so many > > > >> prebuilt object files without GNU PROPERTY. > > > > > > > >Please see the slides in > > > > > > > >https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8 > > > > > > > >which includes > > > > > > > >Dynamic Linker for Single Global Definition > > > >• Check the single global definition marker on all components, the executable > > > >and its dependency shared libraries. > > > >• Issue an error/warning if the marker is not consistent on all components. > > > > > > This is not appealing from a compatibility point of view. > > > It is common that a system has mixed shared objects: > > > > > > -fsingle-global-definition => a.so (marker value 1) > > > no -fsingle-global-definition => b.so (marker value 0 or no marker) > > > Issuing a warning will be annoying. > > > > > > > I updated my proposal to > > > > Dynamic Linker for Single Global Definition > > • Check the single global definition marker on all components, the executable > > and its dependency shared libraries. > > I find that I forgot (in so many of my previous messages) to mention > that the name "single global definition" may give a false impression. > For example, a dynamic STV_DEFAULT STB_WEAK/STB_GLOBAL symbol defined > in a shared object can still be interposed. > > > • Disallow copy relocation against definition with the STV_PROTECTED > > visibility in the shared library with the marker. > > If this is for GNU ld x86 only, I'm fine with it:) > > gold and ld.lld just emit an error unconditionally. I think non-x86 > GNU ld ports which never support "copy relocations on protected data > symbols" may want to make the diagnostic unconditional as well. > Well, while (Michael Matz and ) I think compatibility check for "copy > relocations on protected data symbols" is over-engineering (and > Alan/Cary think it was a mistake), if you still want to add it, it is > fine for me... > For Clang, I hope we will not emit such a property, because Clang > never supports the "copy relocations on protected data symbols" > scheme.The issue is that libfoo.so used in link-time can be different from libfoo.so at run-time. The symbol, foobar, in libfoo.so at link-time has the default visibility. But foobar in libfoo.so at run-time can be protected. ld.so should detect such cases which can lead to run-time failures.> > • For systems without function descriptor: > > • Disallow non-GOT function pointer reference in executable without > > the marker to the > > definition with the STV_PROTECTED visibility in a shared library with > > the marker. > > I think this can be unconditional, because the "pointer equality for > STV_PROTECTED function address in -shared" case hasn't been working > for GNU ld for at least 20 years... > Many ports don't even produce a dynamic relocation.True. But see above. You may not care about such use cases. But I believe that ld.so should not knowingly and silently allow such run-time failure to happen.> I don't mind if you add it just for symmetry, but it just feels unneeded. > > > • Use the address of the function body as function pointer on functions with the > > STV_PROTECTED visibility, which are defined in shared libraries with the marker. > > > > > > -- > > H.J.-- H.J.
H.J. Lu via llvm-dev
2021-Jun-18 02:45 UTC
[llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX
On Thu, Jun 17, 2021 at 5:49 PM Fāng-ruì Sòng <maskray at google.com> wrote:> > On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu <hjl.tools at gmail.com> wrote: > > > > On Thu, Jun 17, 2021 at 5:06 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > > > > > On 2021-06-17, H.J. Lu wrote: > > > >On Thu, Jun 17, 2021 at 1:25 PM Fāng-ruì Sòng <maskray at google.com> wrote: > > > >> > > > >> On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu <hjl.tools at gmail.com> wrote: > > > >> > > > > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray at google.com> wrote: > > > >> > > > > > >> > > On 2021-06-17, H.J. Lu via llvm-dev wrote: > > > >> > > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu <hjl.tools at gmail.com> wrote: > > > >> > > >> > > > >> > > >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools at gmail.com> wrote: > > > >> > > >> > > > > >> > > >> > 1. GNU_PROPERTY_UINT32_AND_LO..GNU_PROPERTY_UINT32_AND_HI > > > >> > > >> > > > > >> > > >> > #define GNU_PROPERTY_UINT32_AND_LO 0xb0000000 > > > >> > > >> > #define GNU_PROPERTY_UINT32_AND_HI 0xb0007fff > > > >> > > >> > > > > >> > > >> > A bit in the output pr_data field is set only if it is set in all > > > >> > > >> > relocatable input pr_data fields. If all bits in the the output > > > >> > > >> > pr_data field are zero, this property should be removed from output. > > > >> > > >> > > > > >> > > >> > If the bit is 1, all input relocatables have the feature. If the > > > >> > > >> > bit is 0 or the property is missing, the info is unknown. > > > >> > > > > > >> > > How to use AND in practice? > > > >> > > Are you going to add .note.gnu.property to all of crt1.o crti.o > > > >> > > crtbegin.o crtend.o crtn.o and miscellaneous libc_nonshared.a object > > > >> > > files written in assembly? > > > >> > > > > > >> > > >> > 2. GNU_PROPERTY_UINT32_OR_LO..GNU_PROPERTY_UINT32_OR_HI > > > >> > > >> > > > > >> > > >> > #define GNU_PROPERTY_UINT32_OR_LO 0xb0008000 > > > >> > > >> > #define GNU_PROPERTY_UINT32_OR_HI 0xb000ffff > > > >> > > >> > > > > >> > > >> > A bit in the output pr_data field is set if it is set in any > > > >> > > >> > relocatable input pr_data fields. If all bits in the the output > > > >> > > >> > pr_data field are zero, this property should be removed from output. > > > >> > > >> > > > > >> > > >> > If the bit is 1, some input relocatables have the feature. If the > > > >> > > >> > bit is 0 or the property is missing, the info is unknown. > > > >> > > >> > > > > >> > > >> > The PDF is at > > > >> > > >> > > > > >> > > >> > https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/0690db0a3b7e5d8a44e0271a4be54aa7/linux-gABI-and-or-2021-01-13.pdf > > > >> > > >> > > > > >> > > >> > -- > > > >> > > >> > H.J. > > > >> > > >> > > > >> > > >> Here is the binutils patch to implement it. > > > >> > > >> > > > >> > > > > > > >> > > >If there are no objections, I will check it in tomorrow. > > > >> > > > > > >> > > If the use case is just ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA, it'd be > > > >> > > very kind of you if you can collect more use cases before generalizing > > > >> > > this into a non-arch-specific GNU PROPERTY. > > > >> > > > > > >> > > The "copy relocations on protected data symbols" thing is x86 specific > > > >> > > and only applies with gcc+GNU ld+glibc. > > > >> > > Non-x86 architectures don't have this thing. > > > >> > > gold doesn't have this thing. > > > >> > > clang doesn't have this thing. > > > >> > > > > >> > It will be used to remove copy relocation and implement canonical function > > > >> > pointers, which will benefit protected data and function. > > > >> > > > >> The action items in > > > >> https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8#note_593822281 > > > >> can be applied without a GNU PROPERTY. > > > >> > > > >> If we want to enforce the link-time check that a shared object is no longer > > > >> compatible with copy relocations, just make the shared object's non-weak > > > >> definitions protected, and add a GNU ld diagnostic like gold > > > >> (https://sourceware.org/bugzilla/show_bug.cgi?id=19823) > > > >> > > > >> --- > > > >> > > > >> For functions, > > > >> > > > >> On x86-64, gcc -fpic has been using leaq addr()(%rip), %rax since at least > > > >> 4.1.2 (oldest gcc I can find on godbolt): > > > >> > > > >> __attribute__((visibility("protected"))) > > > >> void *addr() { return (void*)addr; } > > > >> > > > >> // a protected non-definition declaration is the same. > > > >> > > > >> // while asm(".protected addr") can use GOT, it is super rare if ever exists > > > >> // outside glibc elf/vis*.c > > > >> > > > >> I have checked all of binutils 2.11, 2.16, 2.20, 2.24, 2.35. The have > > > >> the same diagnostic: > > > >> > > > >> relocation R_X86_64_PC32 against protected function `addr' can not > > > >> be used when making a shared object > > > >> > > > >> I think we can assert that taking the address of a protected function > > > >> never works with GNU ld. > > > >> So no compatibility concern. > > > >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116985.html) > > > >> doesn't need any GNU PROPERTY. > > > >> > > > >> --- > > > >> > > > >> For variables, if an object file/archive member does not have GNU PROPERTY, do > > > >> you consider it incompatible with "single global definition"? That is why I > > > >> mentioned crt1.o crti.o crtbegin.o crtend.o crtn.o and libc_nonshared.a members > > > >> written in assembly. > > > >> > > > >> If you consider such an object compatible with "single global definition", I > > > >> don't see why a GNU PROPERTY is needed. > > > >> > > > >> If you consider such an object incompatible with "single global definition", I > > > >> don't see how "single global definition" benefits can be claimed giving so many > > > >> prebuilt object files without GNU PROPERTY. > > > > > > > >Please see the slides in > > > > > > > >https://gitlab.com/x86-psABIs/x86-64-ABI/-/issues/8 > > > > > > > >which includes > > > > > > > >Dynamic Linker for Single Global Definition > > > >• Check the single global definition marker on all components, the executable > > > >and its dependency shared libraries. > > > >• Issue an error/warning if the marker is not consistent on all components. > > > > > > This is not appealing from a compatibility point of view. > > > It is common that a system has mixed shared objects: > > > > > > -fsingle-global-definition => a.so (marker value 1) > > > no -fsingle-global-definition => b.so (marker value 0 or no marker) > > > Issuing a warning will be annoying. > > > > > > > I updated my proposal to > > > > Dynamic Linker for Single Global Definition > > • Check the single global definition marker on all components, the executable > > and its dependency shared libraries. > > I find that I forgot (in so many of my previous messages) to mention > that the name "single global definition" may give a false impression. > For example, a dynamic STV_DEFAULT STB_WEAK/STB_GLOBAL symbol defined > in a shared object can still be interposed. >"single global definition" means that only one global definition will be used at run-time. It doesn't mean that there are no multiple symbols with the same name. H.J.