From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id C0B083858D39 for ; Fri, 8 Oct 2021 17:37:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C0B083858D39 Received: by mail-pl1-x629.google.com with SMTP id c4so6637475pls.6 for ; Fri, 08 Oct 2021 10:37:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=xdvrM8sfpPabFBYoRDYCPtG9lLit4TB/ZCldWf8qrDY=; b=IOw++46EJ0RkpcCkyE7lR3mcn+FvG0iS2D8A8haj8aOAjtv4TdoXz6KTRs4alGoyzM 6YD/N2lPhpK1QsSW1v5SriwbRxKWk9R1QsK1Sl09fnyett8EKyYS6vOl4F9ek6rwqYIX 9FW63X4zzkDg9qgAqkTxh73Rgivptjq3vuBx5to7W3ohbOTLCLY8z0v0WBC9h9gMORMC Vcm0agKgCJLjFuTuqLRklW8Pg7QJR/9YQOUrIX+PLZrDrEL04OQBG4gUH5mvZxVIXVlj ebkbwyvi4TqSdQGeYkzpXEEVBVBwZ8U3xs9L81x1tTUWHSOT/Ivu7euiv9ECvg34Jijl LFaA== X-Gm-Message-State: AOAM531umvuhY+G5VclcTL1bwKwfDd9HZ/4ljaY2JY8MiHHqUm3/UPg1 yg5M5VIC6Jbcu0K+KoCP8wXAkA== X-Google-Smtp-Source: ABdhPJy980JROKvcr1l8ebQpkZLZyBJW3pDCcUBiKh6Ra3Y6QSew85X6IY23qqAoIDTOZSrvgaZYQw== X-Received: by 2002:a17:902:ea05:b0:13f:4b5:cda2 with SMTP id s5-20020a170902ea0500b0013f04b5cda2mr10756167plg.86.1633714635595; Fri, 08 Oct 2021 10:37:15 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:62c5:f086:cfa4:c4ed]) by smtp.gmail.com with ESMTPSA id t6sm8418pfh.63.2021.10.08.10.37.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 10:37:14 -0700 (PDT) Date: Fri, 8 Oct 2021 10:37:10 -0700 From: Fangrui Song To: "H.J. Lu" Cc: GNU C Library , Binutils Subject: Re: [PATCH] elf: Support DT_RELR relative relocation format [BZ #27924] Message-ID: <20211008173710.zwv5akxjexe2ykqp@google.com> References: <20211008065740.1485737-1-maskray@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-18.3 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 17:37:18 -0000 On 2021-10-08, H.J. Lu wrote: >On Thu, Oct 7, 2021 at 11:58 PM Fangrui Song via Binutils > wrote: >> >> PIC objects (especially PIE and symbolic shared objects) usually have many >> relative relocations. In 2017/2018, SHT_RELR/DT_RELR was proposed on >> https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/GxjM0L-PBAAJ >> ("Proposal for a new section type SHT_RELR") and welcomed by many parties >> (including Solaris). This packed format can typically save 95% dynamic >> relocation section size for PIE. The vaddr size of a PIE can be 10% smaller. >> >> * Chrome OS folks have carried a local patch for a while (latest version: >> https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-libs/glibc/files/local/glibc-2.32). >> I.e. this feature has been battle tested. >> * Android bionic supports DT_RELR. >> * The Linux kernel has supported CONFIG_RELR since 2019-08 >> (https://git.kernel.org/linus/5cf896fb6be3effd9aea455b22213e27be8bdb1d). >> * A musl patch (by me) exists but is not applied: >> https://www.openwall.com/lists/musl/2019/03/06/3 >> >> I believe upstream glibc should support DT_RELR to benefit all Linux >> distributions. >> >> As of linker support (to the best of my knowledge): >> >> * LLD support DT_RELR. >> * https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/main/sys-devel/binutils/files/ >> has a gold patch. >> * GNU ld feature request https://sourceware.org/bugzilla/show_bug.cgi?id=27923 >> >> I wish that GNU ld and gold maintainers can implement the feature as well :) > >This feature should be implemented in GNU linker first before getting >into glibc. > > >H.J. Why? I think the situation is quite different from other features where we generally want producers before consumers. The feature is validated by multiple parties and has multiple independent implementations and has an implementation in a glibc supported linker (LLD). Landing into glibc first can do GNU linker folks a favor: they don't need to apply the glibc patch themselves to validate correctness of the linker change.