| Summary: | [1.4.3] crosstap doesn't work on qemuppc | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] Meta-yocto | Reporter: | Yi Zhao <yi.zhao> |
| Component: | meta-yocto | Assignee: | Paul Eggleton <bluelightning> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | Undecided | CC: | adrian.dudau, alexandra.safta, alexandru.c.georgescu, dvhart, ke.zou, poky.bs.watcher, poky.watcher, tom.zanussi, yi.zhao |
| Version: | 1.4.3 | ||
| Target Milestone: | --- | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | Regression (Used to work) |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
Yi Zhao
2014-03-12 03:14:42 UTC
I'm not sure what to do with this; the fix is definitely in the kernel source branch we're using for qemuppc. Tom, any suggestions? At this point, I would suggest bisecting to figure out what caused the regression - if I'm not mistaken, the number of commits between broken and not should be pretty small. Well, FWIW I just tried this on a fresh build of 1.4.2 and it failed there, so this isn't a 1.4.3 regression. (CentOS 6.5 build machine.) (In reply to comment #3) > Well, FWIW I just tried this on a fresh build of 1.4.2 and it failed there, > so this isn't a 1.4.3 regression. (CentOS 6.5 build machine.) I tested it on original 1.4 , it also failed. Could we re-test this on master just to make sure it definitely works there? *** Bug 6016 has been marked as a duplicate of this bug. *** IIRC, this was a result of the way later gcc compiles the kernel causing some issues in the debuginfo that scrambles the function entries and variable locations. We have had this kind of failures before at Enea, in particular with the scheduler.stp file. We wrote some patches around the issue for scheduler.stp but those do not solve the root cause. Some related bugs are already reported/fixed upstream, not sure if they help with our problem : http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 https://sourceware.org/bugzilla/show_bug.cgi?id=15123 I would say we need to investigate if the existing fixes solve our problem and, if not, push the problem upstream. (In reply to comment #7) > IIRC, this was a result of the way later gcc compiles the kernel causing > some issues in the debuginfo that scrambles the function entries and > variable locations. > > We have had this kind of failures before at Enea, in particular with the > scheduler.stp file. We wrote some patches around the issue for scheduler.stp > but those do not solve the root cause. > > Some related bugs are already reported/fixed upstream, not sure if they help > with our problem : > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 > https://sourceware.org/bugzilla/show_bug.cgi?id=15123 > > I would say we need to investigate if the existing fixes solve our problem > and, if not, push the problem upstream. If you look at the yocto bugs mentioned e.g. 4099 and 5403, you can see that the fix was incorporating those upstream gcc and systemtap fixes. The fixes did work and were verified by QA at that point - apparently the whole situation is so fragile that unrelated patches added to the point release broke it again. You mentioned that you have patches that fix the issue - if could please submit them, that would help. For master, I'll try upgrading systemtap to the very latest commit and see if it fixes the problem. If it does, great, if not, we may just have to remove systemtap support for ppc unless someone comes up with fixes. For 1.4.3, we may or may not be able to upgrade to the latest systemtap, if not, we'll probably have to remove support for ppc unless someone can come up with fixes. It's not a great use of our time to be chasing down bugs in fundamentally broken software. |