Re: Yocto prelink status

[Mark Hatle <mark.hatle@kernel.crashing.org>]

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