From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id D284A3858430 for ; Fri, 29 Oct 2021 19:36:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D284A3858430 Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-84-CoY6oxj1OZ-ul_WVZJ-6Wg-1; Fri, 29 Oct 2021 15:35:59 -0400 X-MC-Unique: CoY6oxj1OZ-ul_WVZJ-6Wg-1 Received: by mail-qv1-f71.google.com with SMTP id e10-20020a0cd64a000000b0038422ec2242so8578688qvj.19 for ; Fri, 29 Oct 2021 12:35:58 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:organization:in-reply-to :content-transfer-encoding; bh=hOl9oU85RN4Tp72miydy15Yk24qMLekrbjujIWZjykA=; b=JHAT+TslfGMNJ5lZkjCz/KJ43MDSeOO8XAIspixcL7yqNCBYGGal8o/Tqq4/vQTZEB ccyIDzHzgN12JezKn/a0EZzMolKFxb6EVn+r/SKaxfAufiAEHh2hzn47pqq6E/wTyBam ZpyEGz/e3ZpvBnq+Sb/duWcAM0N4wtfsGPcwV8rAwNaSOa2HNU40AG7ZgJYTpORW0Lel H18OB/R8y7hKQN4r6Y0zQ7YVmkY4oum36pdO0qh7LpaFZyAYtCw0jmj55rpY20ECkBaU ik/cJneqkHFsNu43lBU9X1g7e11aSC6SIY44E0tGNBk9HhHOUwvj47CHFuXKnlI9ZSBL 3Nvg== X-Gm-Message-State: AOAM5310UZ7tIyrmNn4IaC3cXzqc1lHHjF6AffatHrUJaHZ/qAIONQY9 gbFyzywJJ/eG+G46W2A3sLXHQVgMXfur26qQyCwI2wtYGWaOClzbSOBmlBZLYg/wKQzttjvBVzB ODNarm+Ti5YZzsG5GCXhA X-Received: by 2002:ac8:7c53:: with SMTP id o19mr3244540qtv.37.1635536158510; Fri, 29 Oct 2021 12:35:58 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzFPPkBQUbpNwrh3J7hoZ8NjosQ7lL7/SkBq/4B9TQ2PooXN3uP+cg8H9I69n0RqJcSxe8kVA== X-Received: by 2002:ac8:7c53:: with SMTP id o19mr3244518qtv.37.1635536158315; Fri, 29 Oct 2021 12:35:58 -0700 (PDT) Received: from [192.168.1.16] (198-84-214-74.cpe.teksavvy.com. [198.84.214.74]) by smtp.gmail.com with ESMTPSA id f3sm2312660qtf.55.2021.10.29.12.35.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Oct 2021 12:35:57 -0700 (PDT) Message-ID: <2ec94948-f730-94f5-5df1-2de5cc71bb71@redhat.com> Date: Fri, 29 Oct 2021 15:35:56 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.0 Subject: Re: [PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924] To: =?UTF-8?B?RsSBbmctcnXDrCBTw7JuZw==?= Cc: libc-alpha@sourceware.org, binutils@sourceware.org References: <20211017005020.2645717-1-maskray@google.com> <1763c6f4-dfb9-e102-84d6-892ee2a3208a@redhat.com> From: Carlos O'Donell Organization: Red Hat In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP 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, 29 Oct 2021 19:36:05 -0000 On 10/29/21 14:38, Fāng-ruì Sòng wrote: > On Fri, Oct 29, 2021 at 11:21 AM Carlos O'Donell wrote: >> >> On 10/16/21 20:50, Fangrui Song via Binutils wrote: >>> PIE and 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 is a pre-standard. RELR >>> usually takes 3% or smaller space than R_*_RELATIVE relocations. The >>> virtual memory size of a mostly statically linked PIE is typically 5~10% >>> smaller. >> >> We've been going over this patch on the weekly Monday patch queue review. >> >> I took a note to point out that one of the blockers here is that it is difficult >> to immediately test this work because it requires a working glibc build using >> ldd (which has support for DT_RELR). > > No:) There may be a misunderstanding. > > To test the feature: a DT_RELR executable is needed. > Currently only ld.lld --pack-dyn-relocs=relr supports generating > DT_RELR binaries, > but glibc itself does not need to be linked with ld.lld. This is true. However, running the entire testsuite with ld.lld and DT_RELR gives wider coverage and improves confidence in the feature. > If the patch is accepted, GNU ld built glibc will support DT_RELR > programs linked by ld.lld. I agree, but in that scenario, lacking the ability to link the entire testsuite with ld.lld reduces testing coverage for the feature. >> What is the status of the lld support patches for glibc? > > aarch64 and x86-64 work well for me. ... but they aren't yet committed? Do we have a patchwork series for them? https://patchwork.sourceware.org/project/glibc/list/?series=4199 > Seems that Adhemerval may be interested in adding a lld configuration > to scripts/build-many-glibcs.py checking version of ld... 12.0.1, bad ... configure: error: *** These critical programs are missing or too old: LLD *** Check the INSTALL file for required versions. What's the fix for this? >> If we made progress on the lld support then we'd be able to more easily review >> a testable configuration and keep the review going forward. >> >> -- >> Cheers, >> Carlos. >> > -- Cheers, Carlos.