Re: Prelink problems -- need help!

[Mark Hatle <mark.hatle@windriver.com>]

On 10/26/15 11:10 AM, Phil Blundell wrote:
> [Cc list trimmed]
> 
> On Mon, 2015-10-26 at 09:28 -0500, Mark Hatle wrote:
>> As you can see, pretty much everything is currently broken and I'm
>> struggling to
>> find community people with the right skill sets to help me resolve
>> the issues.
> 
> I think it's true that prelink is a technology which has largely had
> its day, and I could well imagine that upstream Red Hat is no longer
> very interested in it.  https://fedorahosted.org/fesco/ticket/1183 has
> a summary of some of the reasons why.
> 
> Before investing any significant amount of time in fixing up prelink
> (and from what you've described it sounds like it might indeed be a
> significant effort to get it working again on all platforms) it might
> be a good idea to make sure we are still convinced that prelink
> provides useful and meaningful benefits for OE-core users.
> 

I do think prelink has a purpose.  Especially for embedded systems.

The biggest reason I see against prelink is ASLR.  I agree 100% that if you want
ASLR (Address Randomization) you should not be using the prelinker.

Usually secondary reasons include if you are doing field upgrades at a package
level -- it means you also need the ability to prelink on the device which cause
have other performance ramifications and such during this upgrade process.

I agree with some of the information on the Fedora hosted link you pointed to,
but disagree with others.

While some of the modern hashing techniques and such do improve run-time dynamic
link performance, there is still a hit that we must take.  For devices that need
quick boot times, quick startup, or are memory constrained, the prelinker can
still help.  (Memory usage on very small systems is a good example.  Memory
usage can be reduced in larger applications by reducing the number of
Copy-on-write pages required to handle the relocation information.)

I probably would not use the prelinker on a workstation/server any longer.  I
might not use it on a 'larger' embedded system, but on a more traditional
embedded system I do think it still has merit.

(Probably a discussion for the future, due to the ASLR, is should the prelinker
be enabled by default -- even if it works -- but that is a discussion for later.)

> If the answer to that is yes then I probably could spare a bit of time
> to look at the ARM and MIPS issues at least.

I can certainly use any help you have.  I have someone looking into the ARM
issues with me.  It APPEARS the primary behavior there has to do with IFUNC
behavior to things like memcpy has changed, causing the prelinker to do the
wrong thing(s).  But I have few additional details at this time.

I've reached out to parts of the MIPS community for help, but we'll see if I get
any type of response.  (MIPS, especially 32-bit, I'm very surprised has broken
recently.  I haven't seen many changes in regard to the way binaries are loaded
on MIPS -- so the issue must be related to a more fundamental optimization or
bug in the prelink.)

Thanks for the offer, let me know if you find anything.  I'll certainly respond
as I make progress trying to go through the issues.

--Mark

> p.
>