[yocto] prelink support

[Kyle Russell]

The cross_prelink_staging branch seems to work for our ARM Cortex-A53
configuration.

The only issue that I ran into was building src/rtld/dl-open.c.  I guess
the GCCVERSION we declared (4.9%) was defaulting to a language standard
that didn't support for loop initial declarations.

On Mon, Jun 20, 2016 at 9:15 AM, Mark Hatle <mark.hatle at windriver.com>
wrote:

> On 6/20/16 7:24 AM, Kyle Russell wrote:
> > It looks like the image-prelink support is still disabled in master
> because of
> > an issue with IFUNC symbol relocation.
> >
> >
> https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta-poky/conf/local.conf.sample?id=8debfea81e69d038bd2d56314b272cb74f5582ed
> >
> > Is there still a problem, or is it safe to reenable image-prelink?  I
> see a "Fix
> > ARM IFUNC support" in the prelink-cross repo, but that appears to have
> been
> > committed several months before image-prelink was disabled.  We'd like
> to enable
> > image-prelink on a build off jethro.
> >
> > Any help or links to a recent discussion thread would be helpful.
> Thanks!
> >
> >
>
> The ARM fix is for a different IFUNC problem.
>
> Disabling the prelinker was caused by a serious of problems that started
> with a
> fork failure traced back to shared library processing orders.
>
> (For comments below, I'm referring to the repository:
> http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/)
>
> The initial problem, IFUNC processing, showed that processing order of the
> shared libraries could lead to a case where the wrong IFUNC was used.  We
> believe this particular issues was fixed in the staging tree.
>
> In the tree you'll see a cross_prelink_staging branch.  In that branch the
> fix
> is commit ID: "8f55afd84b3580b1f1d6af904e8c2a39221055b7"  This fixes the
> 'fork'
> issue by ensuring the proper sort order for shared library processing.
> (This
> was finally fixed in March.)
>
> However with that we determined there was at least one more issue related
> to
> section ordering.  The prelink test suite was failing due to various
> integrity
> checks showing that once we prelinked something, we could not reverse the
> process.  It has taken us months to identify the cause of the problem and
> the
> solution.  (Cause BTW was a change in binutils-2.22 that no longer ensured
> that
> the section order was sorted by offset order... a small amount of the
> prelink
> processing needed to be changed to deal with that behavior.  It's taken far
> longer to fix then we had ever expected.)
>
> See commit (33be255d62af533189f1f7bc66c06602b703980a) in the
> cross_prelink_staging branch.
>
> With this commit, I think the two major issues have been resolved.  I've
> got a
> small set of additional patches I need to put into place -- and then I
> have to
> finish going through the regression suite to verify everything is working
> properly.  (Seems like every time I get to this step, something else comes
> up
> and I'm not getting it done...)
>
> So if you've read this far, the point in all of this is that I THINK that
> the
> cross_prelink_staging branch and current top commit
> "33be255d62af533189f1f7bc66c06602b703980a" are working.  However, I've not
> completed testing so I'm not sure of that yet.
>
> If you can help with testing, you should modify your prelink recipe to use
> the
> 'cross_prelink_staging' branch, and the 33be255 commit.  Verify that this
> is
> working for your use cases.  If you are using glib or graphical
> environments pay
> particular attention to process startup messages that indicate failures.
>
> If this IS working for you, I'd like a reply back with the architecture and
> processor you are using so I can add that to my matrix.  (I'm traveling
> for the
> next couple of days, and then should be back in the officer where I hope to
> finish my regression testing, apply the last couple of patches from Gentoo
> developers, regression test again and prepare a release version.)
>
> Any help is appreciated, thanks for understanding why this is taking so
> long.
>
> --Mark
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20160622/043be392/attachment.html>