Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX

["H.J. Lu" <hjl.tools@gmail.com>]

On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song <maskray@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@gmail.com> wrote:
> >>
> >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu <hjl.tools@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.

-- 
H.J.