From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <pb@pbcl.net>
Received: from pbcl.net (pbcl.net [IPv6:2a01:4f8:c2c:5794::1])
 by sourceware.org (Postfix) with ESMTPS id 2828A3858407
 for <libc-alpha@sourceware.org>; Fri, 21 Jan 2022 17:09:14 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2828A3858407
Received: from pb by pbcl.net with local (Exim 4.92)
 (envelope-from <pb@pbcl.net>)
 id 1nAxPT-0004DB-OQ; Fri, 21 Jan 2022 18:09:11 +0100
Date: Fri, 21 Jan 2022 18:09:11 +0100
From: Phil Blundell <pb@pbcl.net>
To: Szabolcs Nagy <szabolcs.nagy@arm.com>
Cc: Richard Purdie <richard.purdie@linuxfoundation.org>,
 libc-alpha@sourceware.org, mark.hatle@kernel.crashing.org,
 "Robert Berger@yocto.user" <robert.berger.yocto.user@gmail.com>,
 Nicolas Dechesne <nicolas.dechesne@linaro.org>
Subject: Re: Yocto prelink status
Message-ID: <20220121170911.GD1021@pbcl.net>
References: <3830fa36af3e6e8637197f49366ee0af158d721f.camel@linuxfoundation.org>
 <20220121105844.GC1021@pbcl.net> <20220121162320.GI3294453@arm.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20220121162320.GI3294453@arm.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS,
 SPF_HELO_PASS, SPF_PASS, TXREP 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 <libc-alpha.sourceware.org>
List-Unsubscribe: <https://sourceware.org/mailman/options/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=unsubscribe>
List-Archive: <https://sourceware.org/pipermail/libc-alpha/>
List-Post: <mailto:libc-alpha@sourceware.org>
List-Help: <mailto:libc-alpha-request@sourceware.org?subject=help>
List-Subscribe: <https://sourceware.org/mailman/listinfo/libc-alpha>,
 <mailto:libc-alpha-request@sourceware.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jan 2022 17:09:15 -0000

On Fri, Jan 21, 2022 at 04:23:20PM +0000, Szabolcs Nagy wrote:
> glibc plans to support the DT_RELR format for more compact representation
> of relative relocs. see bug 27924.
> 
> (i believe this is used on android/chromeos for the reason you cited.)

Yes.  There are actually three problems with large number of RELATIVE relocs:

1. They take up a lot of space in .rel.dyn or equivalent which causes binary
bloat.

2. All of them need to be processed at startup (you can't do them lazily) and
this adds delay before you get to main()

3. Data pages that have had relocations applied to them are now dirty and
unshareable so they occupy more space in memory.

As I understand DT_RELR it solves the first of these but not the other two.

Phil