From: Phil Blundell <pb@pbcl.net>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
Nicolas Dechesne <nicolas.dechesne@linaro.org>,
carlos@redhat.com, libc-alpha@sourceware.org,
mark.hatle@kernel.crashing.org,
"Robert Berger@yocto.user" <robert.berger.yocto.user@gmail.com>
Subject: Re: Yocto prelink status
Date: Fri, 21 Jan 2022 11:58:44 +0100 [thread overview]
Message-ID: <20220121105844.GC1021@pbcl.net> (raw)
In-Reply-To: <3830fa36af3e6e8637197f49366ee0af158d721f.camel@linuxfoundation.org>
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.
p.
next prev parent reply other threads:[~2022-01-21 10:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-20 22:51 Richard Purdie
2022-01-21 10:58 ` Phil Blundell [this message]
2022-01-21 16:23 ` Szabolcs Nagy
2022-01-21 17:09 ` Phil Blundell
2022-02-03 15:26 ` Richard Purdie
2022-02-03 15:43 ` Mark Hatle
-- strict thread matches above, loose matches on Subject: below --
2022-01-19 19:52 Adhemerval Zanella
2022-01-19 20:28 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220121105844.GC1021@pbcl.net \
--to=pb@pbcl.net \
--cc=adhemerval.zanella@linaro.org \
--cc=carlos@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=mark.hatle@kernel.crashing.org \
--cc=nicolas.dechesne@linaro.org \
--cc=richard.purdie@linuxfoundation.org \
--cc=robert.berger.yocto.user@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).