From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42e.google.com (mail-pf1-x42e.google.com [IPv6:2607:f8b0:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 3E15B3844040; Sat, 19 Jun 2021 01:10:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3E15B3844040 Received: by mail-pf1-x42e.google.com with SMTP id q192so2470714pfc.7; Fri, 18 Jun 2021 18:10:19 -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; bh=BpzSWYk3esd0AfN7QoxKjmtxCPQGg5f2uNh8wPf9Ofw=; b=WkRcn1Lk1tUJxpbiwvyPIPCB7chez8yMmxIKzFY6RsOmIX1Mi2OoGKe+Zki65y1HJW UDLkH+a0JXkgT6K0BVa2u2ne5hwmzghWbHFg7xkZfn7i92JXsJzzh5lgi5kB2+w7F6Al eIZDNKxwRJeSX8tS9QlW6Z/UHNuXDRcUGyplGQtaPLG26iGCyRZF6fJ4p7Fp6sjlXku0 UIKNhm3X+7t9ALxYBqhdMz8fbTyaobVVXq7su2EW5ZnzjfBH2xeQ2IZdItQfAF+NKZNT wj8tHHFLsIGKbBAk+8k5n5TvVMtEuwKFHFABQCljIgoA16jqBdLDvMhoosgXNBb2+PhZ YYxw== X-Gm-Message-State: AOAM530KwpeJYuBKdtrH05Do3GZ+IhZ0WKoCJDrkIX9hCsJdklFDPl7i QtJbAKo9M3VQbs3iAIddHkfCFWnAbGOJ3TB7sW4= X-Google-Smtp-Source: ABdhPJw/qEvAvKeMiasTBeGoiIlKnkP/8I3CfZeQo2tGfk7z2orr6KxziORQEpAxPPsS6/V5C3+osXEEdh6tbsMe+Ro= X-Received: by 2002:a63:3d8f:: with SMTP id k137mr12666610pga.161.1624065018144; Fri, 18 Jun 2021 18:10:18 -0700 (PDT) MIME-Version: 1.0 References: <20210618213450.qdasgofw6hklzxip@google.com> In-Reply-To: <20210618213450.qdasgofw6hklzxip@google.com> From: "H.J. Lu" Date: Fri, 18 Jun 2021 18:09:42 -0700 Message-ID: Subject: Re: [llvm-dev] RFC: Add GNU_PROPERTY_1_NEEDED To: Fangrui Song Cc: GNU gABI gnu-gabi , GCC Development , Binutils , GNU C Library , llvm-dev@lists.llvm.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3025.9 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: Sat, 19 Jun 2021 01:10:20 -0000 On Fri, Jun 18, 2021 at 2:34 PM Fangrui Song wrote: > > On 2021-06-18, H.J. Lu via llvm-dev wrote: > >Add GNU_PROPERTY_1_NEEDED: > > > > #define GNU_PROPERTY_1_NEEDED GNU_PROPERTY_UINT32_OR_LO > > > >to indicate the needed properties by the object file. > > > > I am fine with this logical OR style usage. But see below, do we need it > for ld.so runtime check? I implemented run-time check on users/hjl/single-global/master branch: https://gitlab.com/x86-glibc/glibc/-/commits/users/hjl/single-global/master with tests: [hjl@gnu-cfl-2 build-x86_64-linux]$ elf/tst-protected1a copy relocation against non-copyable protected symbol=protected1 in file=/export/build/gnu/tools-build/glibc-cet-gitlab/build-x86_64-linux/elf/tst-protected1moda.so [hjl@gnu-cfl-2 build-x86_64-linux]$ elf/tst-protected2a `protected1' in main and moda doesn't have the same address non-canonical reference to canonical protected function symbol=protected1 in file=/export/build/gnu/tools-build/glibc-cet-gitlab/build-x86_64-linux/elf/tst-protected2moda.so [hjl@gnu-cfl-2 build-x86_64-linux]$ I prefer these over random run-time failures. > (As I mentioned previously, I do not know how an AND-style property can > be used/deployed if old object files without the .note.gnu.property is > considered to have a value of 0.) > > >Add GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION: > > > > #define GNU_PROPERTY_1_NEEDED_SINGLE_GLOBAL_DEFINITION (1U << 0) > > > >to indicate that the object file requires canonical function pointers and > >cannot be used with copy relocation. > > In https://sourceware.org/pipermail/gnu-gabi/2021q2/000481.html you gave > a rationale > > "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." > > First, I think such dynamic symbol visibility change is uncommon. I can imagine that some libraries want to switch to protected symbols. > Second, if ld.so finds that a symbol lookup for (st_value==0 > st_shndx==SHN_UNDEF) will bind to a STV_PROTECTED definition in a shared > object, can the diagnostic be moved there? > The compatibility property is per-symbol and the symbol lookup is a > perfect place for a diagnostic, like a symbol versioning error. > > > I guess GCC folks may get noticed if you start a thread adding > -fsingle-global-definition, otherwise many people who have opinions may > just ignore threads about GNU PROPERTY addition. Binutils changes are at https://gitlab.com/x86-binutils/binutils-gdb/-/tree/users/hjl/property/master GCC changes are next. > > > >The PDF file is at > > > >https://gitlab.com/x86-psABIs/Linux-ABI/-/wikis/uploads/9eca2f2defe62b0c5015bf2e3e8a9f05/Linux-gABI-1_needed-2021-06-18.pdf -- H.J.