From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) by sourceware.org (Postfix) with ESMTPS id B42C838515E7; Thu, 17 Jun 2021 23:01:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B42C838515E7 Received: by mail-pl1-x635.google.com with SMTP id h1so3726139plt.1; Thu, 17 Jun 2021 16:01:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ABTQeRC+Riw8BJWEX1YYQWXTAjlk7AwBUrbPgk1N/Ag=; b=Y3MGTikumqAPJN3ZFTYiXCYGp0NEy0ar82oi2zSVQHtHIH0h62ckPFac37DGrmZ+Hl Yqanni6wrN/38vXQP7aOAMiKuKbSjZCADSL5HIPYeqkbXJuOZcOqdKlWTG59rrFEVuWK NuUPzDqjb659PmhYaOyGg2I/Qb7gZ5dTHG83NdsY2bR8XuXiuKQgPmQVRN+tvQmV6bUx ttxvppXYhxOUIwptIF6NZetPZ9c+4U5ib9l+dbssaEXk476vUERH9yJzY+qqh6LUJO7H B6bywFDup8wBC0hPTgeiRH/QJgCB2b2D3xDEWrCkUbqSBagSwzPbLL0UbK291Q5ov1Nm SJsA== X-Gm-Message-State: AOAM531Bhh4oxLa748SoG8kKx+5wvlJlGGJFnZ9g7K9yZ8RG8GIVvq/8 Xj1rhdJDVLPKdw9LWnJbCoG5cAWIf3zfykt0arw= X-Google-Smtp-Source: ABdhPJy0Pi6tln32BZUqk+MiQs5c4Qa8oTnrpq2i1EXsGS+OBb1d4KHFU27VXUpVdhL5y9lESDk+yhqm+z6SAaHkEe0= X-Received: by 2002:a17:90b:10e:: with SMTP id p14mr1647359pjz.153.1623970908912; Thu, 17 Jun 2021 16:01:48 -0700 (PDT) MIME-Version: 1.0 References: <20210617193825.zzjyoybttajksw5x@google.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 17 Jun 2021 16:01:12 -0700 Message-ID: Subject: Re: [llvm-dev] RFC: Add GNU_PROPERTY_UINT32_AND_XXX/GNU_PROPERTY_UINT32_OR_XXX To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: GNU gABI gnu-gabi , GCC Development , Binutils , GNU C Library , llvm-dev@lists.llvm.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3025.3 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gnu-gabi@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gnu-gabi mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2021 23:01:53 -0000 On Thu, Jun 17, 2021 at 1:25 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > On Thu, Jun 17, 2021 at 12:46 PM H.J. Lu wrote: > > > > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song wrot= e: > > > > > > On 2021-06-17, H.J. Lu via llvm-dev wrote: > > > >On Thu, Jan 21, 2021 at 7:02 AM H.J. Lu wrote: > > > >> > > > >> On Wed, Jan 13, 2021 at 9:06 AM H.J. Lu wrot= e: > > > >> > > > > >> > 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 al= l > > > >> > relocatable input pr_data fields. If all bits in the the output > > > >> > pr_data field are zero, this property should be removed from out= put. > > > >> > > > > >> > If the bit is 1, all input relocatables have the feature. If th= e > > > >> > 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 out= put. > > > >> > > > > >> > If the bit is 1, some input relocatables have the feature. If t= he > > > >> > 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/0690db0a= 3b7e5d8a44e0271a4be54aa7/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 b= e > > > very kind of you if you can collect more use cases before generalizin= g > > > this into a non-arch-specific GNU PROPERTY. > > > > > > The "copy relocations on protected data symbols" thing is x86 specifi= c > > > 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 funct= ion > > 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 long= er > 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=3D19823) > > --- > > 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 e= xists > // 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.htm= l) > doesn't need any GNU PROPERTY. > > --- > > For variables, if an object file/archive member does not have GNU PROPERT= Y, 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 m= embers > 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 definitio= n", I > don't see how "single global definition" benefits can be claimed giving s= o 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 =E2=80=A2 Check the single global definition marker on all components, the = executable and its dependency shared libraries. =E2=80=A2 Issue an error/warning if the marker is not consistent on all com= ponents. =E2=80=A2 Disallow copy relocation against definition in the shared library= with the marker. =E2=80=A2 For systems without function descriptor: =E2=80=A2 Disallow function pointer reference in executable without the mar= ker to the definition with the STV_PROTECTED visibility in a shared library with the marker. =E2=80=A2 Use the address of the function body as function pointer on funct= ions with the STV_PROTECTED visibility, which are defined in shared libraries with the ma= rker. This provides the capability to detect the ABI change at run-time as well a= s optimize for STV_PROTECTED symbol lookup. My linker implementation is at https://gitlab.com/x86-binutils/binutils-gdb/-/tree/users/hjl/property/mast= er I will implement the dynamic linker change. > If we still want "absolutely no copy relocation for -fno-pic", just use G= OT for > default visibility external data access > (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D98112) > Some architectures may not like it (i386/ppc32), just leave them behind. > Modern architectures can do it. When things get matured, add a ld warning= , > then add a ld.so warning. When things get more matured, change the warnin= gs to > errors. > > Such changes should use a mechanism similar to glibc LD_DYNAMIC_WEAK (wea= k can > preempt global) and Solaris LD_BREADTH (breadth-first order based depende= ncy > order) and LD_NODIRECT (direct bindings). At some point, introduce a beha= vior > change. I don't think how an explicit marker can improve the compatibili= ty > story. The conceived compatibility issues likely don't really exist for The compatibility issue does exist. Please see the linker tests I added. > functions. For copy relocations, I think we may need to wait an extended = period > of time. That is what the single global definition marker is used for. --=20 H.J.