From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 8BCB03858D35 for ; Thu, 3 Feb 2022 15:49:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8BCB03858D35 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from [192.168.2.107] ([70.99.78.137]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 213Fi096005153; Thu, 3 Feb 2022 09:44:00 -0600 Message-ID: <091f08ba-5a36-8fc9-e5a9-47dfd26bbcf2@kernel.crashing.org> Date: Thu, 3 Feb 2022 09:43:59 -0600 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: Yocto prelink status Content-Language: en-US To: Richard Purdie , Phil Blundell Cc: Adhemerval Zanella , Nicolas Dechesne , carlos@redhat.com, libc-alpha@sourceware.org, "Robert Berger@yocto.user" References: <3830fa36af3e6e8637197f49366ee0af158d721f.camel@linuxfoundation.org> <20220121105844.GC1021@pbcl.net> <12aca993234dc6d6f3ea5c85298f18e4b8ca8816.camel@linuxfoundation.org> From: Mark Hatle In-Reply-To: <12aca993234dc6d6f3ea5c85298f18e4b8ca8816.camel@linuxfoundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.5 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE 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: Thu, 03 Feb 2022 15:49:15 -0000 On 2/3/22 9:26 AM, Richard Purdie wrote: > On Fri, 2022-01-21 at 11:58 +0100, Phil Blundell wrote: >> On Thu, Jan 20, 2022 at 10:51:31PM +0000, Richard Purdie via Libc-alpha wrote: >>> 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. >> >> The benefits of prelink tend to be more noticeable with large C++ DSOs because >> they have a lot of RELATIVE relocs which can be eliminated entirely during >> prelinking. JUMP_SLOTs are resolved lazily in any case so the benefit of >> doing that in advance is smaller, and most modern programs don't have a lot >> of GLOB_DATs at all. >> >> I'm slightly puzzled by the increase in memory footprint because prelink is >> supposed to eliminate the dirty GOT pages caused by doing reloc fixups at >> runtime. But that does indeed seem to be what the numbers say. >> >> Obviously there is a fundamental tension between ASLR and prelink. I don't >> think PIE is fundamentally incompatible with prelink (we can prelink PIC DSOs >> for example) but if you're going to be loading at a different address each >> time then clearly prelinking is not useful. Given that the direction of >> travel does seem to be towards ASLR everywhere it does seem that prelink is >> going to be a bit of a losing proposition. >> >> I would be slightly sad to see prelink go away entirely and if anybody on >> the Yocto side wanted to pick it up and make it work again then I would be >> happy to help them with that but I don't think I realistically have either >> the time or the enthusiasm to champion that effort myself. > > I did just want to loop back and agree with this last paragraph in particular. > I'm sad to see it being removed but I have too many other issues and not the > right amount of time to spend on this one. I suspect there could be ways to > configure things for better numbers but I doubt those configurations would be > acceptable so it doesn't really seem worth looking into them. > > Whilst you mention making it work again, I'd imagine without the glibc support > that would be hard? I doubt this is something we could carry without upstream > help. > > In looking at removing it from Yocto Project, I did notice we filed a bug in > 2016: > > https://sourceware.org/bugzilla/show_bug.cgi?id=20488 > > which never made any progress, which is kind of a sign of the problem too :(. We > still carry that patch. This bug is partially what started the discussion on removing it. Someone from libc-alpha contacted us trying to understand the bug report. --Mark > Cheers, > > Richard