From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) by sourceware.org (Postfix) with ESMTPS id D34823857818 for ; Fri, 29 Oct 2021 19:53:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D34823857818 Received: by mail-qk1-x734.google.com with SMTP id bm16so10420742qkb.11 for ; Fri, 29 Oct 2021 12:53: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:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=C9rfDlEfqIbFtZmVbVCyO26cbqJsNNaiUluCspBK0yw=; b=OQpfy55tuRoycAnw470Mw3QaKfVq02+81Ct6rw0RMmj4Xio+DqCJsY8VbQ8sE1I4m3 ZDG0itTCXSVRc58SoX53j88yn3fBMa7/mD9QO8S2I6rHm9ZffXLgXcyGTfVuAlkjyz5e oQwO6mik6g9kAh5ApXpfKMma07Op98GkTvS0+P7k6N+vpBsskbtGa+x3wSMKL9yZgLxf ilqWS6T8k6yFhwe/l9sJAmH6d0y+BrGviMmY4TZWXYnFsosbPELHm4kF2W5/c3l/NAMf jtuJxaGMbFPemEAcbmAPgE4KkF+7tJcvv7S6dtvV0Kwwd1AQry31BEA6od0hf+oiKahC KGPg== X-Gm-Message-State: AOAM5313vxhXznaqBQ/9j0ZUPFqXCwaWDfoVbgVxsIwyq1b+PpIoXSES 85UhHJRJavU0DddWUJG1DR+vrQ== X-Google-Smtp-Source: ABdhPJwYJmMl64dFRkl4JU7/zPUwKZHqtlgJBbVnldlnsbuXXEqvsyydIk9bDK0JJyhS3o2NkbYgWg== X-Received: by 2002:a05:620a:288b:: with SMTP id j11mr10629922qkp.257.1635537196373; Fri, 29 Oct 2021 12:53:16 -0700 (PDT) Received: from ?IPV6:2804:431:c7cb:b64f:a500:ef25:9b66:6e05? ([2804:431:c7cb:b64f:a500:ef25:9b66:6e05]) by smtp.gmail.com with ESMTPSA id m6sm4655832qti.38.2021.10.29.12.53.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 29 Oct 2021 12:53:16 -0700 (PDT) Message-ID: Date: Fri, 29 Oct 2021 16:53:14 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2 Subject: Re: [PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924] Content-Language: en-US To: Carlos O'Donell , =?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> <2ec94948-f730-94f5-5df1-2de5cc71bb71@redhat.com> From: Adhemerval Zanella In-Reply-To: <2ec94948-f730-94f5-5df1-2de5cc71bb71@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=unavailable 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:53:19 -0000 On 29/10/2021 16:35, Carlos O'Donell via Binutils wrote: > 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? I summarized the previous status of glibc plus lld on [1]. In a short, only x86_64, i686, and aarch64 works without testcase regressions (i686 does show one regression, elf/ifuncmain6pie). I am working on arm, I could get it build and having the testcase without only 11 regression (all of them related to ifunc). I plan to send the patches soon. The powerpc builds but either loader or libc fails to run. The riscv also builds with an extra patch to set -mno-relax (to avoid R_RISCV_ALIGN generation since lld does not support it), but I didn't not actually test if works as expected. The other supported architectures, sparc64 and mips, seems to be broken and it would require much more work. [1] https://sourceware.org/pipermail/libc-alpha/2021-October/132315.html