From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) by sourceware.org (Postfix) with ESMTPS id EC0CE3858407 for ; Thu, 20 Jan 2022 22:51:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EC0CE3858407 Received: by mail-wm1-x32d.google.com with SMTP id f202-20020a1c1fd3000000b0034dd403f4fbso14230667wmf.1 for ; Thu, 20 Jan 2022 14:51:33 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:subject:from:to:cc:date:user-agent :mime-version:content-transfer-encoding; bh=RZl2qfVktCkKeOtya04J9QlSVliB+UE5H9rxYXyczhc=; b=cHUxyot4CGnME98nHlPhD89aIwtbVNj1CTrd94MefFQ1QdYM1ekplG4gWRUzX66z/M 7PNq/ryS82nVOCZu58q7iG+NCpRS3KTOYkHFD6Mezch7yVTMa2ThN55RYeUiSg3lMaPx USAbkloFoKjN9mmxcTQE6XsYX9NHii7k0rTMiYTL++QLVBnntCCwIm7SPYervQkr016H YAZoePPwobwji4Wzo/xBYfrLEYUMocFCavIBUHmJB01TIJs5V0ArwnkwjzT3S07HUEm+ cBw3RHtkAYAwhJ+U+a3Di6kuPs3PSRmUBPAF0IWIMJVPXasOo8Y2Y2MKJ4ukNptKtxgn RPgg== X-Gm-Message-State: AOAM5324FH8FO9QM/UkvO7f8sm/NawmiOY1cDLha24/ML2eZM7/Ol+FO gHZRCMz1FH+WSgSFFzUKwbPmdw== X-Google-Smtp-Source: ABdhPJx7FXSNu2m7huGFgWpRRT4I5yGP/aQx+ah1T2efepIhG8cSvXP7RnDqo6uvA41KZmfkOB57ng== X-Received: by 2002:a5d:64e8:: with SMTP id g8mr1140566wri.286.1642719092949; Thu, 20 Jan 2022 14:51:32 -0800 (PST) Received: from ?IPv6:2001:8b0:aba:5f3c:4dc7:4aef:2fda:b7ee? ([2001:8b0:aba:5f3c:4dc7:4aef:2fda:b7ee]) by smtp.gmail.com with ESMTPSA id y13sm4803490wry.113.2022.01.20.14.51.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jan 2022 14:51:32 -0800 (PST) Message-ID: <3830fa36af3e6e8637197f49366ee0af158d721f.camel@linuxfoundation.org> Subject: Re: Yocto prelink status From: Richard Purdie To: Adhemerval Zanella , Nicolas Dechesne , carlos@redhat.com, libc-alpha@sourceware.org Cc: mark.hatle@kernel.crashing.org, Khem Raj , "Robert Berger@yocto.user" Date: Thu, 20 Jan 2022 22:51:31 +0000 Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4-1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, URIBL_RED 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: Thu, 20 Jan 2022 22:51:36 -0000 Hi, I was asked to take a look at this thread. I can probably represent the Yocto Project and where we are with this. > Recent discussions on glibc maillist about prelink supported is leading > us to deprecate and remove its support on glibc. Last year it was hinted > that Yocto seems to be maintained the project, although without much > development [1]. That is a fair summary. It is something some of our users do use but it hasn't had much active development and we're aware there are bugs. We don't really have people with the right expertise to address them right now unfortunately. > A recent issue [2] with a change to support llvm lld to build glibc lead > to a issue when prelink is used on the loader itself (which does not > make sense since kernel will be responsible and it does not really > care about prelink). > > Finally the discussion on a recent patch proposal [3] to fix an issue > for sym dependency makes me believe that prelink is de facto deprecated, > since it does not work on most binaries in most architectures (20-30% > of the system is capable of prelinking according to Mark) and it tends > to get worse with new ABI extensions (for instance we plan to support > DT_RELR on 2.36 [4]). For instance, prelink on a Ubuntu 20.10 on > x86_64 prelink -p shows that no binary could prelinked. We did some investigation into this last year. You can see the discussion about disabling it here: https://lists.yoctoproject.org/g/poky/search?q=prelink The bottom line was that with PIE enabled, it wasn't able to work. Since we enable PIE by default, we did drop enabling prelink by default since it was not doing anything useful in that case. One of our community members did dive into it further and wrote up what he found: https://embed.endfa.net/yocto-cross-prelink-1/ https://embed.endfa.net/cross-prelink-time-memory/ Bottom line was that there was some very slight speed ups and the memory usage was possibly worse with prelink but it was marginal. With other more specific test cases and libraries with complex/large symbol tables, the results may be different. > Mark also stated that for embedded prelinked still yields some gain > for loading time (specially for system boot) and memory consumption > (although I am not sure if it really yield any gain for recent > ABIs that avoid design such TEXTREL and writable PLT). > > My plan is to remove prelink support for 2.35, at least to stir some > discussion. Unfortunately I don't have a straightforward replacement, > I see prelink as very narrow solution that aims to fix some glibc design > drawnbacks (such as not being focused for static linking, neither to > lower memory consumption). > > So I would to like if Yocto plan is to continue support prelink somewhat, > or if you have any other ideas. If glibc drop it, I doubt it would be viable for us and we'd just have to follow. I liked the fact that prelink did give some speed wins and that given Yocto Project aims to support constrained use cases, having it available as a tool for users was a good thing for us. We are struggling in a number of areas for feature development/maintenance and since prelink is already struggling on our side, we wouldn't go it alone with that. I will post up something to the Yocto Project community highlighting we will likely have to drop it. I did see a patch today from someone fixing prelink support in a corner case so it is being used by people but I'm not sure anyone would step up to help resolve the bigger issues on the glibc side or ours. We would likely attempt to drop it sooner than later as we have an LTS coming up and it may make sense for us to do that now if we know that is the direction glibc upstream are going. Cheers, Richard > At glibc side, we are trying to fix > some long-standing issues related to static linking (we deprecated > static dlopen, and we working on the NSS support), but it still required > some work to be on par with other static oriented libc. > > [1] https://sourceware.org/pipermail/libc-alpha/2021-August/130404.html > [2] https://sourceware.org/pipermail/libc-alpha/2021-October/131989.html > [3] https://sourceware.org/pipermail/libc-alpha/2022-January/135189.html > [4] https://sourceware.org/bugzilla/show_bug.cgi?id=27924