[OE-core] Prelink problems -- need help!
Mark Hatle
mark.hatle at windriver.com
Tue Oct 27 00:40:52 UTC 2015
On 10/26/15 11:45 AM, Mark Hatle wrote:
> 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.
I just wanted to update folks on where I'm at.
On the Intel IA32 architecture, the problem appears to have been triggered by
the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA that went in after March of this year.
I've not been able to track down what is causing the bad behavior -- but fully
dropping support for that class type allows the prelink to "mostly work".
On ARM the issues appear to have some problem related to IFUNCs, but I still
don't have any data beyond that at this point.
> --Mark
>
>> p.
>>
>
More information about the Openembedded-core
mailing list