Yocto prelink status

[Richard Purdie]

Hi,

I was asked to take a look at this thread. I can probably represent the Yocto
Project and where we are with this.

> Recent discussions on glibc maillist about prelink supported is leading
> us to deprecate and remove its support on glibc.  Last year it was hinted
> that Yocto seems to be maintained the project, although without much 
> development [1].  

That is a fair summary. It is something some of our users do use but it hasn't
had much active development and we're aware there are bugs. We don't really have
people with the right expertise to address them right now unfortunately.

> A recent issue [2] with a change to support llvm lld to build glibc lead
> to a issue when prelink is used on the loader itself (which does not
> make sense since kernel will be responsible and it does not really
> care about prelink).
> 
> Finally the discussion on a recent patch proposal [3] to fix an issue
> for sym dependency makes me believe that prelink is de facto deprecated,
> since it does not work on most binaries in most architectures (20-30%
> of the system is capable of prelinking according to Mark) and it tends
> to get worse with new ABI extensions (for instance we plan to support
> DT_RELR on 2.36 [4]).  For instance, prelink on a Ubuntu 20.10 on
> x86_64 prelink -p shows that no binary could prelinked.

We did some investigation into this last year. You can see the discussion about
disabling it here:

https://lists.yoctoproject.org/g/poky/search?q=prelink

The bottom line was that with PIE enabled, it wasn't able to work. Since we
enable PIE by default, we did drop enabling prelink by default since it was not
doing anything useful in that case.

One of our community members did dive into it further and wrote up what he
found:

https://embed.endfa.net/yocto-cross-prelink-1/
https://embed.endfa.net/cross-prelink-time-memory/


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.

> Mark also stated that for embedded prelinked still yields some gain
> for loading time (specially for system boot) and memory consumption
> (although I am not sure if it really yield any gain for recent
> ABIs that avoid design such TEXTREL and writable PLT).
> 
> My plan is to remove prelink support for 2.35, at least to stir some
> discussion.  Unfortunately I don't have a straightforward replacement,
> I see prelink as very narrow solution that aims to fix some glibc design
> drawnbacks (such as not being focused for static linking, neither to 
> lower memory consumption). 
> 
> So I would to like if Yocto plan is to continue support prelink somewhat,
> or if you have any other ideas.

If glibc drop it, I doubt it would be viable for us and we'd just have to
follow.

I liked the fact that prelink did give some speed wins and that given Yocto
Project aims to support constrained use cases, having it available as a tool for
users was a good thing for us. We are struggling in a number of areas for
feature development/maintenance and since prelink is already struggling on our
side, we wouldn't go it alone with that.

I will post up something to the Yocto Project community highlighting we will
likely have to drop it. I did see a patch today from someone fixing prelink
support in a corner case so it is being used by people but I'm not sure anyone
would step up to help resolve the bigger issues on the glibc side or ours. We
would likely attempt to drop it sooner than later as we have an LTS coming up
and it may make sense for us to do that now if we know that is the direction
glibc upstream are going.

Cheers,

Richard


>   At glibc side, we are trying to fix
> some long-standing issues related to static linking (we deprecated
> static dlopen, and we working on the NSS support), but it still required
> some work to be on par with other static oriented libc.
> 
> [1] https://sourceware.org/pipermail/libc-alpha/2021-August/130404.html
> [2] https://sourceware.org/pipermail/libc-alpha/2021-October/131989.html
> [3] https://sourceware.org/pipermail/libc-alpha/2022-January/135189.html
> [4] https://sourceware.org/bugzilla/show_bug.cgi?id=27924