Yocto prelink status

Phil Blundell pb@pbcl.net
Fri Jan 21 10:58:44 GMT 2022


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.


More information about the Libc-alpha mailing list