From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102c.google.com (mail-pj1-x102c.google.com [IPv6:2607:f8b0:4864:20::102c]) by sourceware.org (Postfix) with ESMTPS id A3AFF387740D; Fri, 18 Jun 2021 02:46:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A3AFF387740D Received: by mail-pj1-x102c.google.com with SMTP id x21-20020a17090aa395b029016e25313bfcso5012953pjp.2; Thu, 17 Jun 2021 19:46:03 -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=uUHGs2KS4LQ7DIeeBuDAsv7+ibd+WNfcHShZwgsmubk=; b=aWztZF9tE+k3ZfsKB7Sanc+ivQ4hBMMBcFWXZzwGRTMjjK4TtZrmXdp+KTQA0f8OdN X6Mrk/CjlymaGZKYu1ocZNLNn0PG5vM0rJHbeBZT2g3WyjcTvUlIsRK7wrWMG8p4LdeV bDhO2I6nLx6GgqONba6PI8e5pI3zN00WBeatuW4iSSenz+pSMPZX0foC+iPZhzPJzXIx o2ORJWEdYzaqn4U3L4RivohAH7wZV4GYo30HNQWgYw5Lhlae2hd56D9GoZgINyME52d3 ZVyokKLCnH0sBTwZXC7qhnvInRyR6rQVfmtCjqUQeLxpaHFTu3ot2A2O6Suqc/mSW3CK 3vDQ== X-Gm-Message-State: AOAM530w33yvG6PwVo9jUorCEhtU+vPshfSrIOjwPI/xLqiW3ZASAlLW dPtNXKUIP4Q8axTtWnE3/JA/DOtT8dIiA6b8d2M= X-Google-Smtp-Source: ABdhPJwL4xM08zGcTQspPktFZA4jAEZikEVMVgrXv88gpmmwcEsK0CzGWfwufeizvdonPHGqCegMS+jLZZIGJxJvjKo= X-Received: by 2002:a17:902:8f8f:b029:107:810b:9ee5 with SMTP id z15-20020a1709028f8fb0290107810b9ee5mr2790176plo.4.1623984362798; Thu, 17 Jun 2021 19:46:02 -0700 (PDT) MIME-Version: 1.0 References: <20210617193825.zzjyoybttajksw5x@google.com> <20210618000600.c7yh6twgbukmyouj@google.com> In-Reply-To: From: "H.J. Lu" Date: Thu, 17 Jun 2021 19:45:26 -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.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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: Fri, 18 Jun 2021 02:46:05 -0000 On Thu, Jun 17, 2021 at 5:49 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > On Thu, Jun 17, 2021 at 5:24 PM H.J. Lu wrote: > > > > On Thu, Jun 17, 2021 at 5:06 PM F=C4=81ng-ru=C3=AC S=C3=B2ng wrote: > > > > > > On 2021-06-17, H.J. Lu wrote: > > > >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 wro= te: > > > >> > > > > >> > On Thu, Jun 17, 2021 at 12:38 PM Fangrui Song wrote: > > > >> > > > > > >> > > 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 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 se= t in all > > > >> > > >> > relocatable input pr_data fields. If all bits in the the= output > > > >> > > >> > pr_data field are zero, this property should be removed f= rom 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 f= rom 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/0= 690db0a3b7e5d8a44e0271a4be54aa7/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 gene= ralizing > > > >> > > 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 canonica= l 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 no= n-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 si= nce 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 h= ave > > > >> the same diagnostic: > > > >> > > > >> relocation R_X86_64_PC32 against protected function `addr' can n= ot > > > >> be used when making a shared object > > > >> > > > >> I think we can assert that taking the address of a protected funct= ion > > > >> never works with GNU ld. > > > >> So no compatibility concern. > > > >> Fixing it (https://sourceware.org/pipermail/binutils/2021-June/116= 985.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_nonsha= red.a members > > > >> written in assembly. > > > >> > > > >> If you consider such an object compatible with "single global defi= nition", I > > > >> don't see why a GNU PROPERTY is needed. > > > >> > > > >> If you consider such an object incompatible with "single global de= finition", I > > > >> don't see how "single global definition" benefits can be claimed g= iving 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 > > > >=E2=80=A2 Check the single global definition marker on all component= s, the executable > > > >and its dependency shared libraries. > > > >=E2=80=A2 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 =3D> a.so (marker value 1) > > > no -fsingle-global-definition =3D> 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 > > =E2=80=A2 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 us= ed at run-time. It doesn't mean that there are no multiple symbols with the s= ame name. H.J.