* prelink support @ 2016-06-20 12:24 Kyle Russell 2016-06-20 13:12 ` Richard Purdie 2016-06-20 13:15 ` Mark Hatle 0 siblings, 2 replies; 7+ messages in thread From: Kyle Russell @ 2016-06-20 12:24 UTC (permalink / raw) To: yocto [-- Attachment #1: Type: text/plain, Size: 614 bytes --] 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! [-- Attachment #2: Type: text/html, Size: 894 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: prelink support 2016-06-20 12:24 prelink support Kyle Russell @ 2016-06-20 13:12 ` Richard Purdie 2016-06-20 13:15 ` Mark Hatle 1 sibling, 0 replies; 7+ messages in thread From: Richard Purdie @ 2016-06-20 13:12 UTC (permalink / raw) To: Kyle Russell, yocto On Mon, 2016-06-20 at 08:24 -0400, 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! Basically, its still broken. I actually ran into a bug the other day caused by the issue where I had prelink enabled locally. I know Mark is working on some fixes but its an onion problem, you fix one thing, then find other issues. Mark can give the full story but right now, its not able to be re-enabled. Cheers, Richard ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: prelink support 2016-06-20 12:24 prelink support Kyle Russell 2016-06-20 13:12 ` Richard Purdie @ 2016-06-20 13:15 ` Mark Hatle 2016-06-20 13:45 ` Kyle Russell 2016-06-22 8:06 ` Kyle Russell 1 sibling, 2 replies; 7+ messages in thread From: Mark Hatle @ 2016-06-20 13:15 UTC (permalink / raw) To: Kyle Russell, yocto 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: prelink support 2016-06-20 13:15 ` Mark Hatle @ 2016-06-20 13:45 ` Kyle Russell 2016-06-22 8:06 ` Kyle Russell 1 sibling, 0 replies; 7+ messages in thread From: Kyle Russell @ 2016-06-20 13:45 UTC (permalink / raw) To: Mark Hatle; +Cc: yocto [-- Attachment #1: Type: text/plain, Size: 3950 bytes --] Thanks, Mark and Richard. Great update! I'll try out the staging branch and report back with results. On Mon, Jun 20, 2016 at 9:15 AM, Mark Hatle <mark.hatle@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 > [-- Attachment #2: Type: text/html, Size: 4861 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: prelink support 2016-06-20 13:15 ` Mark Hatle 2016-06-20 13:45 ` Kyle Russell @ 2016-06-22 8:06 ` Kyle Russell 2016-06-22 14:57 ` Mark Hatle 1 sibling, 1 reply; 7+ messages in thread From: Kyle Russell @ 2016-06-22 8:06 UTC (permalink / raw) To: Mark Hatle; +Cc: yocto [-- Attachment #1: Type: text/plain, Size: 4132 bytes --] 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@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 > [-- Attachment #2: Type: text/html, Size: 5062 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: prelink support 2016-06-22 8:06 ` Kyle Russell @ 2016-06-22 14:57 ` Mark Hatle 2016-06-23 1:37 ` Kyle Russell 0 siblings, 1 reply; 7+ messages in thread From: Mark Hatle @ 2016-06-22 14:57 UTC (permalink / raw) To: Kyle Russell; +Cc: yocto On 6/22/16 3:06 AM, Kyle Russell wrote: > 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. What is the specific error you got? This is the type of stuff I'd like to resolve. Are you using a branch and gcc that is part of OpenEmbedded? If so, I need to know how to configure the system so I can attempt to reproduce and work around the issue. --Mark > On Mon, Jun 20, 2016 at 9:15 AM, Mark Hatle <mark.hatle@windriver.com > <mailto:mark.hatle@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 > > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: prelink support 2016-06-22 14:57 ` Mark Hatle @ 2016-06-23 1:37 ` Kyle Russell 0 siblings, 0 replies; 7+ messages in thread From: Kyle Russell @ 2016-06-23 1:37 UTC (permalink / raw) To: Mark Hatle; +Cc: yocto [-- Attachment #1: Type: text/plain, Size: 1495 bytes --] On Wed, Jun 22, 2016 at 10:57 AM, Mark Hatle <mark.hatle@windriver.com> wrote: > What is the specific error you got? This is the type of stuff I'd like to > resolve. > I don't have the logs on me at the moment for the specific output, but there were two errors (one for 'int scope_cnt' and the other for 'unsigned int cnt') being declared in the for loop initialization, which isn't supported until -std=c99. I was able to move the declaration to the beginning of _dl_show_scope just for testing and prelink finished compiling successfully. Are you using a branch and gcc that is part of OpenEmbedded? If so, I need > to > know how to configure the system so I can attempt to reproduce and work > around > the issue. > I think we're using the gcc compiler that's included in poky. I was running poky at the following commit on jethro. ddbc131 toasterconf.json: exclude releases Toaster can't build The only configuration change that I'm aware of was setting GCCVERSION back to "4.9%" as recommended in http://www.yoctoproject.org/docs/2.1/mega-manual/mega-manual.html#migration-2.0-gcc-5 I had updated the SRCREV and branch in the prelink recipe to point to cross_prelink_staging as you suggested. It simply seems that the version of dl-open.c on cross_prelink_staging just isn't compatible with gcc 4.9, which seems to default to C90. I can dig further into our setup and send specific steps tomorrow if you're not able to get similar results. [-- Attachment #2: Type: text/html, Size: 2708 bytes --] ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2016-06-23 1:38 UTC | newest] Thread overview: 7+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2016-06-20 12:24 prelink support Kyle Russell 2016-06-20 13:12 ` Richard Purdie 2016-06-20 13:15 ` Mark Hatle 2016-06-20 13:45 ` Kyle Russell 2016-06-22 8:06 ` Kyle Russell 2016-06-22 14:57 ` Mark Hatle 2016-06-23 1:37 ` Kyle Russell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.