From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by sourceware.org (Postfix) with ESMTPS id 10F483858D20 for ; Thu, 3 Feb 2022 15:26:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 10F483858D20 Received: by mail-wr1-x42e.google.com with SMTP id j16so5659469wrd.8 for ; Thu, 03 Feb 2022 07:26:21 -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:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=UsYGBdtfvJTVELWcUnVOKMC+/EW3ECFVbNxb+hFHz8I=; b=Ju6DVSubQRywoHR+N9oVa8eHeEkM+Ywl6RaVYgyyYdl1K0ieNVqQkLbbBSQbfS/B1D IbdzACYaxDGZv6cwAtEQcuu2getDyy/zYFq/Y554NOQWnY5z8BBye1Ulv9/JOxhFGn9n g1+qWROW/qv9wDePygIiZIF4sV4mBB0Mum5xnfEjOD1Sa2klB2UvA08cMSczkXbOq13t KRGH9TLzyRtjNL15mj7/ra5iVVpMDuq9miyl/8YvEiDFD5V+oovoPowUU6m6mfh3J4uz sOWXj84ODT/yp2HWN2gw02e/L+CQ2/y+c91lCJt7g6mmmv1oFvtb1OTJVEWm75vgpNMr FCOQ== X-Gm-Message-State: AOAM530e8ttbw+zJn9BR5zrxxVyk8aRwN9ggGg85M6nMiAYcYfmncfW+ y8aR3L5akxWXqox56r6ZOwDTeg== X-Google-Smtp-Source: ABdhPJyzzmjBklNv+e0xEvM0q/eUTkYv6cN3L+bI7vJkMgGNpRgPA0eIqBsc+RE4dLJb3lSI7MWyxg== X-Received: by 2002:a5d:6a8d:: with SMTP id s13mr28941020wru.280.1643901979881; Thu, 03 Feb 2022 07:26:19 -0800 (PST) Received: from ?IPv6:2001:8b0:aba:5f3c:e772:7635:2207:1103? ([2001:8b0:aba:5f3c:e772:7635:2207:1103]) by smtp.gmail.com with ESMTPSA id j19sm8725111wmq.17.2022.02.03.07.26.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 03 Feb 2022 07:26:19 -0800 (PST) Message-ID: <12aca993234dc6d6f3ea5c85298f18e4b8ca8816.camel@linuxfoundation.org> Subject: Re: Yocto prelink status From: Richard Purdie To: Phil Blundell Cc: Adhemerval Zanella , Nicolas Dechesne , carlos@redhat.com, libc-alpha@sourceware.org, mark.hatle@kernel.crashing.org, "Robert Berger@yocto.user" Date: Thu, 03 Feb 2022 15:26:18 +0000 In-Reply-To: <20220121105844.GC1021@pbcl.net> References: <3830fa36af3e6e8637197f49366ee0af158d721f.camel@linuxfoundation.org> <20220121105844.GC1021@pbcl.net> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.40.4-1ubuntu2 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-4.0 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, T_SCC_BODY_TEXT_LINE 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, 03 Feb 2022 15:26:27 -0000 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. Cheers, Richard