From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x532.google.com (mail-pg1-x532.google.com [IPv6:2607:f8b0:4864:20::532]) by sourceware.org (Postfix) with ESMTPS id 5ED743858427 for ; Mon, 1 Nov 2021 04:50:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5ED743858427 Received: by mail-pg1-x532.google.com with SMTP id f5so16123745pgc.12 for ; Sun, 31 Oct 2021 21:50:11 -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:content-transfer-encoding :in-reply-to; bh=dAj0fn0f2c3YPuJdOHZ+PtkUb+WCtjVrwPcimd2Pn6c=; b=HkjlCJZKMZUx6LoigryIWrcrfE7Y1CBjsYrVsXKRn/LblQ0D9TE1mBfA7/mdGUvmVR sXEoFLpa66lzOTlVJM2NQNOuagX9TdLIdSKyIY4nuDh4VLA+dq/+g2PTHO/p0yKzmj/o v5kZGQywq3azBZlhIDFvskhuqjHqr0kYRaqtw0Zd6apGe0eG5Xg+dK+DPDBFFsgohVcy LsFyGAlktIBADDyPUlFjkk374cBSvHRyYvgUEEufXtM279d1kS7ggoRTzLBvdAOsWuAw T9tq8EbF3w0Cqet4a4hiXvhJHeJQwi/XyMH0a8aKU6xtgkS7XFrnEoe6fdWs4H0luRsK aslw== X-Gm-Message-State: AOAM5337o+nl6ahqPMOOJHwHyraAcGlZFvg8XYDEhc6BQnD+COWUzyJx ads2DZtbOiWNeimpVr3p6Zp5/Q== X-Google-Smtp-Source: ABdhPJz+yQ2gUB6jUnUPDum5jflMXAZalUmprRJLzoPj9tCuGNkn1UuYb4aoERfrXn1wnuq8uXV1uQ== X-Received: by 2002:aa7:858d:0:b0:481:12de:ce17 with SMTP id w13-20020aa7858d000000b0048112dece17mr1734474pfn.59.1635742210325; Sun, 31 Oct 2021 21:50:10 -0700 (PDT) Received: from google.com ([2620:15c:2ce:200:9a2d:1f6e:ae2f:7442]) by smtp.gmail.com with ESMTPSA id 17sm13893216pfp.14.2021.10.31.21.50.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 31 Oct 2021 21:50:09 -0700 (PDT) Date: Sun, 31 Oct 2021 21:50:05 -0700 From: =?utf-8?B?RsSBbmctcnXDrCBTw7JuZw==?= To: Carlos O'Donell , Adhemerval Zanella Cc: libc-alpha@sourceware.org, binutils@sourceware.org Subject: Re: [PATCH v2] elf: Support DT_RELR relative relocation format [BZ #27924] Message-ID: <20211101045005.cgdr3dv2pczf5yjb@google.com> References: <20211017005020.2645717-1-maskray@google.com> <1763c6f4-dfb9-e102-84d6-892ee2a3208a@redhat.com> <2ec94948-f730-94f5-5df1-2de5cc71bb71@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Spam-Status: No, score=-19.4 required=5.0 tests=BAYES_00, DKIMWL_WL_MED, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH, KAM_INFOUSMEBIZ, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, USER_IN_DEF_DKIM_WL, USER_IN_DEF_SPF_WL autolearn=no 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: Mon, 01 Nov 2021 04:50:13 -0000 On 2021-10-29, Adhemerval Zanella wrote: > > >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. I use a hacked /usr/local/bin/ld to link tst- test- objects with --pack-dyn-relocs=relr: % cat /usr/local/bin/ld #!/bin/zsh output= prev_arg= for arg in "$@"; do [[ $prev_arg == -o ]] && output=$arg prev_arg=$arg done if [[ $output =~ 'tst-|test-' ]]; then exec ~/Stable/bin/ld.lld --pack-dyn-relocs=relr "$@" else exec ~/Stable/bin/ld.lld "$@" fi % ~/Stable/bin/ld.lld --version LLD 14.0.0 (compatible with GNU linkers) % readelf -WS elf/tst-absolute-sym | grep relr.dyn [11] .relr.dyn 00000013: 0000000000000f90 000f90 000020 08 A 0 0 8 Most tests pass, except the 7 nptl tests which spawn a gdb process and do some complex stuff with it: % comm -3 <(grep '^FAIL' tests.sum | sort) <(grep '^FAIL' ../lld0/tests.sum | sort) FAIL: nptl/test-condattr-printers FAIL: nptl/test-cond-printers FAIL: nptl/test-mutexattr-printers FAIL: nptl/test-mutex-printers FAIL: nptl/test-rwlockattr-printers FAIL: nptl/test-rwlock-printers FAIL: nptl/tst-pthread-gdb-attach-static % cat nptl/test-condattr-printers.out Error: Response does not match the expected pattern. Command: print *condvar Expected pattern: pthread_cond_t Response: Cannot access memory at address 0xffffd788 (gdb) The 4000+ PASSes give me confidence that the DT_RELR does the right thing. I read the generic-abi thread in 2019 but just noted that a comment from Ali Bahrami deserved my re-read https://groups.google.com/g/generic-abi/c/bX460iggiKg/m/0PMCJ0hjBAAJ "My free advice (worth what you paid for it) is to roll out the support, and then wait a bit before turning on the use widely, so that the support is in place before it is needed, and to not complicate things with a way to catch time travelers. The window of time where this can be a problem is finite, and once you're past it, you'll be glad to have a simpler system." I hope that I have captured the status well enough in https://maskray.me/blog/2021-10-31-relative-relocations-and-relr#glibc :) >>>> 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? 13.0.0 is needed :) >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